Skip to content

Approvals

An approval step pauses a workflow until the people you choose have decided. The workflow then continues on the path that matches the decision. A decision step looks at the data and picks a path — for example, it sends large orders to an approval and approves small ones automatically.

  1. It works out who must approve, from the policy you wrote.
  2. It asks them by email, and lists the request in their Approvals inbox.
  3. It waits until enough of them have decided, or until time runs out.
  4. It records the outcome, then the workflow continues on the matching path.

A paused run shows who has answered so far, for example 1/2 approved.

You name approvers in the step’s policy. Each entry is one of these:

Entry Means
user:<id> One person in your workspace
role:<name> Everyone in your workspace with that role
team:<slug> Everyone on that team who is also in your workspace
agent:<name> An AI agent that reviews the request and votes

Only people in the workspace that runs the workflow can approve. If someone leaves the workspace while a request waits, their vote is no longer accepted.

Setting What it does
quorum How many approvals are needed. A number, or all.
stages Ask groups one after another, for example a manager first, then legal.
veto People whose single rejection stops the request at once.
min_humans How many of the approvals must come from people. An agent can then vote, but cannot decide alone.

The step stops waiting as soon as the outcome is certain. It does not wait for the last vote if enough people have already approved, or if approval is no longer possible.

Setting What it does
timeout How long to wait for each stage, for example 2d. The default is seven days.
on_timeout What happens when time runs out: timed_out (the default), rejected or approved.
remind_after Send one reminder to anyone who has not answered.
escalation After a set time, also ask more people.

Times are written as a number with s, m, h or d, for example 36h.

A complete example:

{
"stages": [
{ "approvers": "role:manager" },
{ "approvers": "team:legal", "quorum": "all" }
],
"veto": ["role:general-counsel"],
"remind_after": "1d",
"timeout": "3d",
"escalation": { "after": "2d", "approvers": "role:director" }
}

Open Approvals to see what is waiting for you in the current workspace. For each request you can:

Choice Meaning
Approve Yes, as it is.
Reject No. Add a comment to say why.
Abstain You don’t have an opinion. This does not count as an approval.
Edit before approving Change the content, then approve. The workflow continues with your changes. When the step declares which fields may change, you get a form with just those fields; otherwise you edit the content directly.

After you respond, you normally see Your vote is recorded. If the request was closing at the same moment, you may see Your vote was sent and is being processed instead; the run picks the vote up a moment later, and the request’s record shows the result.

The email links straight to the request. If your workspace uses the Slack integration, you can also send the bot a message: approve 1a2b3c4d, or reject 1a2b3c4d too expensive. The code is in the email. If the bot replies that more than one request matches the code, respond from Approvals instead.

Each connection that leaves an approval step can name the outcomes it runs for: approved, approved_with_changes, rejected, timed_out or unresolvable.

A connection with no outcome named runs only when the request is approved. So “approve, then send” is safe by default. To do something on rejection, add a connection labelled rejected. Steps that no connection reaches are skipped.

unresolvable means nobody could be asked — for example, the role you named has no members. The step stops at once rather than waiting for no one.

A decision step holds a small table of rules. Each rule checks values from the workflow’s input or from earlier steps, and sets outputs. The first rule that matches wins.

Amount Route Approvers Quorum
> 10000 review team:finance 2
(anything) auto

Connections that leave a decision step can name a route. An approval step can take its policy from the decision, so the table decides both whether to ask and whom to ask. A table with a mistake in it stops the run with a clear error, in your language. It never quietly takes the default path: a rule that cannot be read, a value that cannot be compared, or a setting the table does not support all stop the run and say which rule and column. Each rule must also evaluate within a few seconds, so a rule that loops over a very large list stops the run too.

Some tools, such as sending an email, can be set to need approval before they run. When an agent wants to use one, the run pauses and asks for approval of that one action, with the exact details shown. Approving with changes runs the action with your edits. Rejecting it tells the agent no, along with your comment.

Every approval request is kept in a permanent record. The record shows who was asked, who answered and how, any comments and changes, and the outcome. Nobody can edit the record. If your workspace’s subscription has lapsed, requests stop sending emails and votes are not accepted until there is an active plan again. A Slack vote is also refused while the workspace is over its usage budget, and the bot’s reply says which of the two it was.