Skip to content
Expedify
Start free
4 min

Human Approval

Stop the workflow and ask a person. The three input modes, what the reviewer sees, what your downstream nodes get back — and why the Rejected path must always be wired.

Some decisions should not be automatic. A discount past a threshold, an AI-drafted email to your largest customer, a refund, anything that is awkward to undo. You still want the other ninety per cent of the workflow to run by itself.

Human Approval is the node that stops and asks. The run pauses, a pending item appears for a reviewer, and nothing downstream happens until they answer.

A worked example

Two answers, two directions

The reviewer's choice decides which arm runs.

ApprovedRejected

Scroll for all 4 steps →

The two arms are named for the two answers. On the canvas they are the handles labelled Approved and Rejected — and everything in this lesson comes back to the second one.

What the reviewer actually sees

The fields that shape the request. The dynamic-options fields beside them build the choices from upstream data instead of a fixed list.

prompt

What it holds
Question or prompt to show the user Defaults to Please review and approve to continue.

inputType

What it holds
Type of input interface One of: options · text · approval Defaults to approval.

options

What it holds
Static options for user to select from (used when optionsSource=static)

showData

What it holds
Display current data to the user Defaults to true.

allowModification

What it holds
Allow user to modify the data before approval Defaults to true.

timeout

What it holds
Timeout in seconds (0 for no timeout) Defaults to 300.

The prompt is the whole brief. The reviewer sees it out of context — not the workflow, not what came before — so “Approve?” is not enough. “This deal has a discount above 20%. Approve it?” lets someone decide without opening anything else.

  • showData puts the record in front of them, which is usually the difference between a considered answer and a reflexive one.
  • allowModification lets them edit before approving. Powerful, and worth thinking about: whatever they change is what continues, so the workflow must be able to cope with values a person typed.

Three ways to ask

approval

The reviewer gets
Approve or Reject.
Use it for
A gate. The default, and usually right.

options

The reviewer gets
Your own list, from options — “Send as is”, “Send with edits”, “Do not send”.
Use it for
A decision with more than two answers.

text

The reviewer gets
A free-text box.
Use it for
When you need a reason or an instruction, not a choice.

With optionsSource set to dynamic, the choices come from upstream data instead of a fixed list — three AI-drafted subject lines, say, for a person to pick between. That is the shape worth remembering: the machine proposes, the human chooses.

What comes back

{{humaninloop_1.selected_option}}

Holds
What they picked.

{{humaninloop_1.user_input}}

Holds
What they typed, in text mode.

{{humaninloop_1.approval_status}}

Holds
The outcome, for logging or a message.

{{humaninloop_1.selected_original_data}}

Holds
The data behind their choice — the full record, not just its label.

The timeout is the part people get wrong

A timeout does not stop the run. It leaves down the Rejected path. So an unwired Rejected arm means a workflow that silently does nothing whenever a reviewer is on holiday — and it looks identical to a workflow nobody triggered. Always wire Rejected, and have it do something visible: a task, a note, a message saying this did not go out and why.

That also means Rejected carries two different meanings — “a person said no” and “nobody answered in time”. Usually you want the same handling for both. When you do not, approval_status tells them apart.

Set timeout to how long is genuinely reasonable to wait: minutes for something someone is watching for, an hour for an end-of-day review, 0 to wait indefinitely for a decision that truly cannot be defaulted. The default is five minutes, which is short for most real approvals.

Where it fits

This node is what makes an aggressive automation safe to ship. The pattern that gets used most: let the AI do the work, then put a person in front of the irreversible step — the send, the refund, the discount. You keep the speed on everything before it and lose nothing on the one step that matters.

Two nodes pause a workflow, for different reasons. A delay waits for time to pass. Human Approval waits for a person. If nobody has to do anything, you want a delay.

Try it

  1. Add a Human Approval after any node, leave inputType on approval, and write a prompt that would make sense to someone who cannot see the workflow.
  2. Wire a different node to each of the two handles and run it. Answer it, and confirm the run resumes down the arm you chose.
  3. Set timeout to 60, run it again, and let it expire. Watch it leave down Rejected rather than fail.
  4. Now switch to options mode with three choices and read {{humaninloop_1.selected_option}} downstream.

Next: Workflow Call — running one workflow from inside another, so a piece of logic lives in one place.

Try this in Expedify →

Related lessons

12 min read

Base rates — what a piece of evidence is actually worth

A face-recognition system that is 99.9% accurate and almost entirely wrong, and a number that sent an innocent woman to prison. Both are the same arithmetic, and it is the arithmetic that decides what any piece of evidence is worth.

Read
10 min read

Confirmation and survivorship — what you never looked for

Two questions about evidence you did not go looking for. One is a rule you have to discover, and one is a pattern in five famous people — and in both, the thing that would have told you the truth is the thing nobody checks.

Read
14 min read

Loss aversion, sunk cost and regression — what it costs you

Four questions you answer about yourself rather than about a scenario, and your own answers are the finding. Then the pattern that makes praise look useless and criticism look like it works, whatever you actually do.

Read