Waits, approvals & resumes

Three steps pause a run mid-flight: wait, approval, and call workflow (while the target runs). A paused run shows as waiting on the runs page.

Pauses are durable

A pause longer than five minutes is a scheduled job, not a sleeping process. Nothing is held in memory: a 3-day wait costs nothing, survives deploys and restarts, and resumes on time. When the pause ends, a fresh job picks the run up exactly where it stopped. (A wait of five minutes or less simply holds its job open and the run stays running; see Wait.)

Deciding approvals

Three doors, one decision path:

• In-app: the waiting run's page shows Approve / Reject; any workspace member can decide.
• Slack: with a Slack connection on the step, the prompt is posted with Approve / Reject buttons; the message rewrites itself with who decided.
• Email: signed one-click links (valid 7 days, no sign-in).

Whichever door, the run resumes down the approved or rejected branch and the decision record (who, when, via which door) becomes the payload.

What you can do with a waiting run

From the run detail: decide it (if it's an approval), or cancel it, which flips the run to cancelled and discards the pause. The step timeline shows exactly which step it's waiting on.

Resume semantics

• The run resumes on the snapshot it started with. A re-activation while a run is paused doesn't change that run.
• Downstream of the pause, everything behaves normally: the decision payload (or the untouched payload after a wait) feeds the next step.
• An expired email link (7 days) leaves the run waiting. Decide it in-app or from Slack, or cancel it.

Gotchas

• The approval payload replaces the upstream payload with the decision record, so carry anything downstream needs into it beforehand (see approval).
• Long waits + frequent triggers = many concurrently-waiting runs; that's fine (they're just rows + scheduled jobs), but the runs page filter waiting is worth a look now and then.