Put a person in the loop

This guide is for authors who want a person to check or decide something before a run continues. Escalations and approvals explains what the reviewer sees.

Ask for approval

Add Approval where the run should wait, and connect it.
Write the Request: what the reviewer should check and decide. Type @ to include values from the run, such as an amount or a customer name.
Wire its exits. Approved and Rejected lead to different blocks, so each decision does what it should.

Each time the block runs, it raises an escalation and the run waits with the status Needs review. Inside a For each item loop, each item raises its own.

The run waits at Approval until someone decides, then leaves by the exit that matches the decision.

Show the data, and let the reviewer fix it

Data to review: map the values the reviewer should check, such as fields read from a document.
Reviewer can: Read the data, or Correct the data before approving. When the reviewer can correct it, map later blocks from the Approval block’s reviewed data, not from the original values, so the corrections are used.
Source documents: attach the PDFs or images the data came from, up to 32. They are shown beside the data.

The block also outputs the Decision and the reviewer’s Reason.

Don’t wait forever

Without a Timeout, the run waits until someone decides. Set one, from 1 minute to 1 year, and the block gets a Timed out exit. Wire it to a reminder, a default decision or a failure.

Send it to the right people

Add a Set Assignees block before the Approval. The escalation goes to the first assignee in its Decisions list, and a timer can move it on to the next. See Decide who owns the work.

An Approval block's settings with its request and data to review, under a warning that no Set Assignees block comes before it.

Without one, the block’s settings warn that no Set Assignees comes before it, as in this example. The warning does not stop you publishing. Escalations raised there stay unassigned and go to the Workspace queue, where anyone in the workspace who can handle escalations can claim them, which suits work a whole team shares.

Assigned people get an in-app notification and an email. Create teams in the organization settings; see Organizations and workspaces.

Ask for a correction instead of failing

Some blocks fail on data a person can fix, such as a missing record or a file that cannot be read. These blocks have a Correction section. Set Correctable failure handling to Request correction and retry. The correction goes to the first assignee of the last Set Assignees block before it. When the block hits one of the listed Correctable faults, the run pauses, the assignee fixes the input, and the block runs again. Inside a For each item loop, each item raises its own escalation, titled with its item number. A waiting item holds up the items behind it, and the run finishes only after someone answers it. The default, Fail the Run, fails the run as usual.

A correction can also ask about an optional setting. Emptying it counts as a fix, and the block runs again without it.

Try it

The first time a draft run reaches the Approval block, it raises a real escalation. Open Escalations, answer it, and check that the run continued down the right exit.

Once the block has a pinned output or a real decision behind it, draft runs use that decision instead of asking again, and the block reads Stand-in decision. See Runs in the editor. To see the escalation again, publish and run the automation.