Skip to main content

Approval Policies

Administration → Approval Policies is where you decide which agent actions require human sign-off. The Approvals page is where people respond to requests; this page decides whether a request is raised at all, and what happens when nobody is named to answer it.

Rules are evaluated in order for every action an agent proposes. The first rule that matches decides the outcome, so ordering is part of the configuration rather than an afterthought.

Outcomes​

A rule resolves an action to one of three outcomes:

  • Ask for approval — The action is held and an approval request is raised. This is the reason the page exists.
  • Allow without asking — The action runs immediately, with no approval request. Use this to carve a safe, high-volume action out of a broader rule.
  • Block entirely — The action is refused outright. No request is raised, because no answer would change the result.

What a rule matches on​

  • Action — The action name the agent is proposing, for example send_email. This is the primary condition.
  • How the run started — Started by a person for a run someone triggered and is present for, or Unattended run for a schedule, webhook or agent-initiated run. The same action can be free when a human is watching and gated when nobody is.
  • Agent — Optional. Leave it empty for a rule that applies to every agent, or name an agent so the rule applies only to that one.
  • Approver — Who is asked. A rule that names nobody falls through to the fallback approver described below.

Note: Separating "started by a person" from "unattended run" is the control most tenants get value from first. An action that is unremarkable when someone is watching the screen is a different proposition at three in the morning with no one accountable.

Order matters​

Rules apply in order, and the first match wins. The list can be sorted by Order applied to see the sequence the engine actually uses, rather than the order rules happen to have been created in.

Put narrow rules above broad ones. A rule that allows one specific safe action must sit above the rule that gates the whole category, or it will never be reached.

Try it​

The Try it panel simulates a decision without waiting for an agent to attempt the action. Enter an action name, choose whether the run was started by a person or unattended, optionally name an agent, and the panel reports what the current rules would do — for example Runs immediately — no approval needed.

Use it after every change. It is the difference between believing a rule works and knowing which rule matched.

Advanced​

The Advanced section holds three settings that apply across all rules. Collapsed, it summarises itself as "Fallback approver, self-approval, and temporary suspensions", and shows a warning badge when any suspension is currently active.

Fallback approver​

Used whenever a rule requires approval but names nobody.

Note: Without a fallback approver, an action that needs approval and matches no named approver is refused, not held. It does not sit in a queue waiting for someone to notice. Setting a fallback is the difference between a delayed action and a failed one.

Self-approval​

Controls what happens when the person who triggered a run is also the person the rule would ask:

  • Refuse — someone else must approve — Separation of duties. The request must go to a different person.
  • Allow, but record it — The requester may approve their own action, and the fact that they did is recorded against their name.

Temporarily suspend approvals​

For incidents. Choose one or more capability categories and a window; actions in those categories run without asking until the window closes.

The window is capped at 24 hours by design — anything longer belongs in a rule, where it stays visible and reviewable rather than sitting as an invisible exception. While any suspension is active, the Advanced header carries a badge showing how many approvals are suspended, so a forgotten suspension is visible from the collapsed state.

Managing the rule list​

  • Search — Filter rules by name.
  • Filter by outcome — Show only rules that ask for approval, allow without asking, or block entirely.
  • Sort — By Order applied to see evaluation sequence, or by Outcome to group rules by what they do.
  • Refresh interval — Off, 30 seconds, 1 minute or 5 minutes, for watching the list while changes are being made elsewhere.

Best Practices​

  • Set a fallback approver before you create your first gating rule — Otherwise the first rule that needs an approver it cannot find refuses the action instead of holding it.
  • Simulate every rule with Try it before relying on it — Especially after reordering, since a rule that is never reached looks identical to a rule that is working.
  • Gate on unattended runs first — Starting with Unattended run on your most consequential actions gives most of the protection for the least friction to people working interactively.
  • Keep Block entirely for things no one should approve — If a human would ever reasonably say yes, use Ask for approval instead; blocking outright removes the conversation.
  • Treat suspensions as incident tools, not configuration — The 24-hour cap is deliberate. A recurring exception belongs in a rule where it can be reviewed.
  • Prefer separation of duties on high-value actions — Set self-approval to refuse, so the person who triggered the run is not the person who signs it off.
  • Approvals — The inbox where people respond to the requests these rules raise.
  • Agents — The agents whose actions these rules govern.
  • Configure — Per-agent configuration, including which capabilities an agent may use.
  • Connections — The third-party connections an approved action may act through.