Approvals
Most automation is fire-and-forget: something happens, the rest runs. Approvals are the exception — the Request approval action stops a running automation partway through and holds everything after it until a person decides.
Nothing before the approval is undone, and nothing after it happens. The rule sits there — for minutes or for weeks — and resumes exactly where it left off the moment someone approves.
That's what makes it useful for the decisions a business doesn't want automated: discounts over a threshold, quotes above a value, refunds, purchase orders, offer letters, anything that goes out under someone's name.
How it works
- The rule fires and runs its actions in order.
- It reaches a Request approval action and pauses. Actions that already ran stay done; every action after the approval is put on hold.
- Everyone named as an approver gets an in-app notification and an email with Approve and Reject buttons.
- The first person to decide settles it — approvals don't need everyone to sign off.
- Approved → the held actions run, picking up the same data the rule was working with, including anything an earlier action produced (a generated document and its share link, for example). Rejected → the held actions never run, and the rejection is recorded against the rule.
Because the paused state is stored, a decision made three days later still resumes correctly.
Setting one up
Add a Request approval action to any automation. It's available on every scope — list, DataTable, form, and document-template rules — so anything that can trigger a rule can be gated.
| Setting | What it does |
|---|---|
| Approvers | The people who may decide. Pick one or several — any one of them can settle it. Required; a rule with no approver can't run the action. |
| Prompt | What they're being asked. Supports the same merge fields as the rest of the builder, so Approve discount for {{task.title}} arrives already filled in. Leave it blank and the request is labelled with the rule's name. |
| Timeout (hours) | Optional deadline. Leave it empty and the request waits indefinitely. |
| If no decision by then | What happens when the deadline passes — see Timeouts. |
Pick members, not guests. Guests are read-only in a workspace and are turned away if they try to decide. Anyone named who isn't an active member of the workspace is dropped when the request goes out, and if that leaves nobody, the action fails rather than silently approving.
Where approvals show up
In the bell menu. The notification dropdown has a dedicated Approvals tab alongside Notifications, with a count of what's waiting on you. The bell badge adds pending approvals to unread notifications, so one number covers both.
In the approvals inbox at /approvals — a Pending tab for what's waiting on you and a History tab showing what was approved, rejected, or timed out. Each row shows the prompt, the rule that raised it, the workspace, how long ago, and a status pill. When something is waiting, the Approvals tab links straight through with View all approvals.
In email. Approvers get a message naming the rule and the prompt, with a one-line summary of what it's about (the task title, the table a row belongs to, or the document that was generated) and Approve / Reject buttons that act in a single click.
Both the in-app notification and the email respect your notification preferences for automations — turn off the email channel and you'll still see it in the app.
Making a decision
Opening an approval shows the workspace, the prompt, and which rule raised it. You can add an optional reason before deciding — it's stored with the decision, which is worth doing on a rejection so the trail explains itself later.
Approving reports back that the automation resumed; rejecting reports that it was halted.
Two conditions must both hold for someone to decide:
- They're named on that approval's approver list, and
- They're still an active member of the workspace, at member level or above.
Removing someone from the workspace therefore revokes their ability to release a pending approval, even one raised while they were still on the team.
An approval can only be settled once. Open one that's already been decided and the page tells you so instead of offering the buttons again.
Timeouts
Leave Timeout empty and the request never expires — it sits in the inbox until somebody decides, however long that takes. That's the right choice when the decision genuinely can't be skipped.
Set a number of hours and you also pick what happens at the deadline:
| Policy | At the deadline |
|---|---|
| Wait forever | Nothing is decided for you. The request is marked Timed out and moves to History; the held actions never run. |
| Auto-approve | Treated as approved. The held actions run exactly as if a person had clicked Approve. |
| Auto-reject | Treated as rejected. The held actions never run. |
Wait forever means "don't decide on my behalf", not "keep waiting past the deadline" — pairing it with a timeout closes the request unresolved rather than approving or rejecting it. If you want a request to stay open indefinitely, leave the timeout blank instead.
A request settled by its timeout is recorded with a reason saying so, rather than being attributed to a person.
Use Auto-approve for a courtesy check where silence should mean consent — a manager gets 24 hours to object to a standard-rate quote, and it goes out if they don't. Use Auto-reject where inaction must be safe: nothing leaves the building without a person saying yes.
What resumes, exactly
Only the actions after the approval are held. Order in the builder is what decides the gate, so put the approval immediately before the first action that shouldn't happen without a yes.
A quote that needs sign-off before it reaches the customer:
| # | Action | Runs |
|---|---|---|
| 1 | Generate document — the Quote template, with a share link | Immediately |
| 2 | Request approval — approver: the owner; prompt: Approve quote for {{task.title}} |
Pauses here |
| 3 | Send email — to the customer, carrying {{generated_document.share_url}} |
Only after approval |
| 4 | Update triggering task — status to Quote Sent | Only after approval |
The quote is prepared the moment the rule fires, so the approver has something concrete to look at — but the customer hears nothing until step 2 clears. Reject it and steps 3 and 4 simply never happen; the draft stays internal.
Swap step 3 for Insert datatable row, Create task, or Send webhook and the same shape gates a purchase order, a refund, or a payment push. Swap it for Send document for signature and the yes doesn't just release an email — the document itself goes out for e-signature, signers invited in order.
Reacting to a yes from another rule
Holding a rule's own tail is one shape. The other is the Approval granted trigger: when any approval on a scope is granted — by a person, or automatically on timeout — a separate rule on that same scope can fire. Its payload carries the original rule's task or row, the approval details ({{approval.prompt}}, {{approval.decided_by_name}}, {{approval.decision_reason}}), and any document the original rule generated.
The recruiting classic: rule one fires when a candidate hits Offer — it drafts the offer letter from a template and requests the manager's approval. Rule two listens for Approval granted and sends that letter to the candidate for signature. The manager clicks one button; the letter emails itself.
Three guardrails to know about: a rule on the Approval granted trigger can't itself contain a Request approval action (a grant would re-fire the trigger in a loop); a declined approval fires nothing — rejection is always terminal; and for a rule with multiple approval stages, the trigger fires only when the last stage clears — an early yes never releases a listener while a later approver is still deciding.
Run history
Approvals are visible in the automation run history like any other activity. A paused run is recorded when it pauses; the resumed run gets its own entry, so the trail reads as a clear before-and-after with the decision — and who made it — in between. A rejection is recorded too, with its reason.
Plan availability
Approvals are available on Pro and above — the same floor as automations themselves, which don't run on the Free plan at all. See pricing.
Next
- Automations — triggers, conditions, and every other action
- Notifications — how approval alerts reach you
- Documents & Templates — the quotes and invoices most often gated
- Members & Guests — who can be an approver