Home Resources Blog Human approvals

Designing human approval steps so people stay in charge

An approval step is only useful if the person behind it can actually decide. Here is how to place one, what to show them and what to do when the answer is no.

4 min readBy The Cadrix team

An approval is a design decision, not a checkbox

It is tempting to treat human approval as a safety feature you switch on. In practice it is a piece of workflow design, and a badly designed one is worse than none: it creates the feeling of oversight without the substance. The person clicks approve because the queue is long, the context is thin and the answer is almost always yes.

The goal is the opposite. The approver should be in a position to disagree, and the workflow should behave sensibly when they do.

Where to place the step

Put the approval immediately before the action that is hard to undo, not at the start of the workflow and not at the end. Before the action, the approver is deciding about something that has not happened yet. At the end, they are only reading a report.

Good candidates are steps that send something outside the company, change a system of record, spend money or grant access. Poor candidates are read-only steps, drafts that a person will edit anyway and anything where the approver cannot see more than the agent already saw.

You rarely need to approve every run. A common pattern is to let routine cases through and route the unusual ones to a person, for example by comparing a value against a limit with a condition before the approval step. That keeps the queue short enough that the reviews stay careful.

What the approver should see

The pause is only as good as the context attached to it. A useful request answers four questions at a glance: what is about to happen, why the workflow thinks it should, what it is based on, and what the alternatives are.

  • The exact action and its target, in plain language rather than raw JSON.
  • The inputs that led to it, such as the original request and the key values.
  • Anything the agent was unsure about, stated rather than hidden.
  • A way to explain a rejection, because the next step often needs the reason.

In Cadrix, the Human Input step pauses the run until a person approves or rejects, and you can write the description they see, fixed or generated, and collect feedback with the decision.

Who should approve

Pick a role, not a single name. If the only approver is on holiday, the queue stops. If the approver is the same person who triggered the run, the check is empty. Decide who is allowed to approve what, and make sure that person has the access and the context to judge.

For higher-stakes steps, consider requiring a different person from the requester. For low-stakes ones, a team queue is usually enough. Either way, write the rule down next to the workflow, because the next person to edit it will otherwise guess.

Design the rejection path

An approval step has two outcomes, and most mistakes come from building only one. Decide in advance what happens on reject: does the workflow stop, notify the requester, ask the agent to try again with the reviewer comment, or hand the case to a different person?

The Human Input step has separate approve and reject outputs for exactly this reason. Connect both. A rejection that dead-ends silently looks, to everyone else, like the workflow is broken.

Plan for silence

People are busy and queues age. Decide what should happen if nobody responds: remind, escalate, expire or keep waiting. Cadrix shows runs that are waiting on a person as Awaiting approval and lists them in a Needs you queue on the home page, so waiting work is visible. How quickly it should be escalated is a process choice for your team to make, not something the tool can guess.

Whatever you choose, do not let a run wait forever with no owner. An unowned pause is a quiet failure.

Keep the decision on the record

The decision, the decider and the surrounding steps should all be part of the run history. That is what makes an approval defensible later: you can show what the person saw, what they chose and what happened next. Retries and re-runs should create new linked runs and leave the original untouched.

For a ready-made checklist covering placement, approvers and what to log, see the approvals guide.

Build your first governed workflow today.

Start on the free plan, bring your own model key, and see a real run traced end to end.