Guide: where to put human approvals, who approves and what to log

Where approvals belong

Place an approval directly before an action that is hard to undo. Four categories cover most cases:

• Leaving the company: messages, documents or files sent to customers, partners or the public.
• Changing a system of record: creating, updating or deleting data in a system others rely on.
• Spending or committing money: payments, refunds, purchase orders, contracts.
• Granting access: accounts, permissions, shared files.

Skip approvals for read-only steps and for drafts a person will edit anyway. Too many approvals train people to click through all of them.

Not every run needs a person

Use a condition before the approval step to send routine cases straight through and unusual ones to a person: for instance, an amount above a limit you define. The right threshold is a business decision. Start strict, look at the approvals that were always accepted, and loosen with evidence.

Who approves

• Choose a role or a small group, not one named person.
• Make sure the approver has the access and context to judge the request.
• For high-stakes steps, require someone other than the requester.
• Name a backup so a holiday does not stop the queue.

What the approver sees

Write the request so it can be decided in under a minute: the exact action, its target, the inputs that led to it and anything the agent was unsure about. The Human Input step lets you write a fixed description or generate one from the run, and optionally collect feedback along with the decision.

Both outcomes

The Human Input step has an approve output and a reject output. Connect both. On reject, decide whether to stop, tell the requester with the reason, retry with the comment, or hand over to another person.

Runs waiting on a person show as Awaiting approval and appear in the Needs you queue on the home page. Decide your own rule for how long a request may wait before someone follows up.

What to log

The run trace records the steps around the approval. For each approval-gated workflow, also agree what your team wants to be able to answer later:

• What was proposed, and on what inputs.
• Who decided, and when.
• The decision and any comment given.
• What happened afterwards, including any retry or re-run.

Retries and re-runs create new linked runs, so the original attempt is not overwritten.

Approval design checklist