Human Input & Approvals

Product documentation

Workflows can pause mid-run and wait — for a person to approve, choose, or type an answer, or for a timer to elapse. A paused run holds no compute; it picks up exactly where it stopped once the answer arrives.

Pause a run for a person

Add a Human Input node where the run needs a decision. Configure it in the node sidebar:

  • Prompt — the question shown to the responder. Supports {{ }} templates, so upstream data can appear in the question.
  • Input Type — Approval (yes/no), Text (free-form), Select (one choice), or Multi-select (several choices).
  • Options — the choices offered for Select and Multi-select.

The node also has a Context input. Wire upstream data into it to carry that data along with the request; it is recorded on the step, and you can inspect it in the step’s details in the run view.

When the run reaches the node, it pauses and its status shows Awaiting input in the run list and run header.

Respond to a paused run

Open the workflow, switch the sidebar to the Runs tab, and select the paused run (see Debugging Runs for the full run view). An Awaiting human input panel shows the prompt and the controls for the configured input type:

  • Approval — Approve and Reject buttons.
  • Text — a text box and a Submit button.
  • Select — a dropdown of the options and a Submit button.
  • Multi-select — a checkbox per option and a Submit button.

Answering resumes the run immediately. The response is validated against the request — a Select answer must be one of the configured options, a Multi-select answer must be a subset of them.

Who can respond

Any teammate who can open the workflow can answer the gate. The run records who responded and when, so approvals stay auditable.

What the workflow receives

The Human Input node completes with these outputs for downstream nodes:

  • response — the answer: a boolean for Approval, a string for Text and Select, a list of strings for Multi-select.
  • responded_by — the responder’s user id.
  • responded_at — when the response was recorded.

Reject does not fail the run. It sets response to false and the run continues. Route on the response — for example, wire response into an If node to send approved and rejected paths in different directions, or into a Stop node to end rejected runs cleanly.

Responding over MCP

AI assistants connected through MCP can answer gates too: the workflow_operations tool’s resume_run operation takes the run and a response matching the gate’s input type.

Multiple gates at once

Parallel branches can each hit their own Human Input node. The run view then shows one response panel per pending gate. Each answer is recorded as it arrives; the run resumes once the last pending gate is answered.

Unanswered gates

A paused run does not wait forever. If nobody responds within 7 days (the default limit), the run fails with a suspension-timeout error — distinct from a crashed run, so abandoned approvals are easy to spot in the run list.

You can also end a paused run yourself: Cancel Run in the run actions menu works on paused runs as well as running ones.

Wait: pause on a timer

The Wait node pauses the run with no human involved:

  • Duration — wait a number of seconds, minutes, hours, or days from now.
  • Until time — wait until an ISO-8601 timestamp. The field supports {{ }} templates, so an upstream node can supply the time. A timestamp already in the past completes immediately.

Short waits (up to 30 seconds) complete inside the step — useful for pacing between API calls. Longer waits park the run and resume it automatically at the scheduled time; the run view shows a Waiting panel with the resume time, and no action is needed.

A wait cannot exceed the 7-day suspension limit; the node rejects longer waits when it runs.

The node outputs resumed_at (when the run continued) and waited_ms (how long it actually waited).

Ending a run early

Two utility nodes end a run before the graph is exhausted — often on the far side of a decision:

  • Stop ends the run as a success. Steps already running in the same parallel group finish; nothing downstream is scheduled. An optional Reason is recorded on the step, and the run view shows a banner noting the run stopped early. Whatever you wire into its input is recorded as the stopping step’s output.
  • Fail ends the run as a failure, with your own Message and Error Code instead of a generic engine error. The message supports {{ }} templates, so it can carry run data: Order {{order.id}} failed validation. Standard failure routing applies — see the On Failure setting described in API Request.

A common pattern: an If node checks a condition, its false branch triggers Stop (“nothing to do”), and its true branch continues into a Human Input approval before the risky action runs.