Human Review

A workflow can stop mid-run and wait for a person. While it waits, the run's status is awaiting_approval — a real, observable state your integration will see, and one you should expect on any workflow whose graph contains a Human Review node.

There are two ways a run ends up there, and they behave differently.

1. A Human Review node

A step you place in the graph yourself. When the run reaches it, Elizon opens a review request, notifies the assignees, and the run sleeps.

Configured in Studio with:

A response is not an approve/reject verdict. The reviewer fills in the declared response fields, and the node's output is an object recording what came back:

{
  "outcome": "responded",
  "requestId": "6c1d0b7a-...",
  "response": { "approved": "yes", "notes": "Margin checks out." },
  "responderEmail": "reviewer@example.com",
  "respondedAt": "2026-09-01T09:14:22.104Z",
  "timeoutAt": "2026-09-02T08:00:00.000Z"
}

The reviewer's own values sit under response, so a downstream node reads one as {{ upstream.<nodeId>.output.response.approved }} — not {{ upstream.<nodeId>.output.approved }}, which resolves to nothing and fails the node. If you want an approval decision, declare a yes_no field and branch on it with an If/Else node.

• A reviewer responds → the node completes and the run continues from there.
• The timeout expires first → the node ends in error, and the run ends as failed with a message naming the elapsed window. Everything downstream of the node is unreachable. There is no "timed out" branch to route around it — plan the timeout accordingly.
• First response wins. If several assignees are listed, the first submission resolves the request; a later one is refused.

2. A budget threshold gate

Not something you place in the graph. If your organization has budgets configured and a run approaches its cap, Elizon parks the run before the next billable node and asks for approval to continue spending. The reviewer sees a message of the form "This workflow run needs approval before it can continue: its <meter> budget is at 85% of the configured cap."

This gate is a yes/no verdict:

• Approved → the run returns to running and continues.
• Rejected, or unanswered after 24 hours → the run ends as failed, with the refusal as its reason. The timeout here is a fixed 24 hours; there is no per-gate setting, because nobody authored the gate.

A run stopped before it started by an exhausted budget is a different outcome entirely — status policy_blocked, decided pre-flight, with no node having run.

Responding to a review

Reviews are answered in Studio, by an organization member who holds the workflow-review permission and whose email address is on the request's assignee list. Both checks apply — the permission decides who can reach the review surface at all, the email match decides who can answer this particular request.

What this means for your integration

• Never call the synchronous endpoint on a graph that can park on a person. It will hit the 30-second limit and return 504. Use /run-async and poll instead.
• awaiting_approval is in flight, not terminal. It counts against your concurrency ceiling for the whole time it is parked — which, with a 30-day timeout, can be a long time. On the community plan, ten workflows waiting on a reviewer will block every other run in the organization.
• Poll patiently. A run waiting on a human is measured in hours or days. Back your polling right off, or cancel the run with POST /workflow-jobs/:jobId/cancel if you no longer need it.

Where to go next

• Workflows API reference — polling a run's status.
• Building a workflow — the rest of the node types.