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 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.

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 — the run flips to cancelled and the pause is discarded. The step timeline shows exactly which step it's waiting on.

Resume semantics

• The run resumes on the snapshot it started with — a publish 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 — 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.