Skip to main content

​
Checkpoint Step

A Checkpoint step stops the run and hands it to a person. It creates a task, notifies the people you named, and parks the run until somebody continues it from the Monitoring page. Whatever that person sends back becomes the step’s result. The step is called Checkpoint when you add it to a flow; its node type is human-in-the-loop.

​
Configuration

The editor has a General tab (name, ID and description) and a Notifications tab holding the whole payload — five fields, and no others.
​
string
The title of the task created for the assignees.
​
string
A summary of the situation that needs a decision. Becomes the task’s description.
​
string
A comma-separated list of user IDs. The editor is a user picker, so you choose people rather than typing IDs. Leave it empty and the step falls back to the account’s configured escalation responders.
​
string
One of lowest, low, medium, high, highest. Sets the task’s priority.
​
string
Escalation Message — the body of the notification sent to each assignee.
Like every step payload, these are JSONPath-resolved before the step runs, so a message can quote the run:

​
What happens when the run reaches it

1

A task is created

A task is opened in the ESCALATE space with your title, description and priority, assigned to the people you named. It carries the run ID and the flow’s subject in its metadata.
2

Assignees are notified

Each assignee is emailed. The email links to the task and to the run itself, at /en/hub/monitoring?run-id=…&highlight-continue=true — which opens Monitoring with the Continue control highlighted.
3

The run parks

The run’s status becomes paused, and its remaining graph and collected data are stored so it can be picked up later. Nothing downstream runs. There is no expiry: a paused run waits indefinitely.
4

Somebody continues it

On the Monitoring page, a paused run shows a green Continue button. It opens a dialog with one field — a message to pass as the output of the paused step — and resuming restarts the run from that step.

​
What the step returns

Exactly what the person typed into the Continue dialog. The step imposes no shape on it: there is no approved flag, no reviewer, no comments and no timestamp. If a later step needs to branch on a decision, the resumer has to supply it and you have to read it back yourself.
The Continue dialog’s message field is parsed as JSON. Type {"approved": true, "note": "fine"} and the step’s result is that object; type bare prose and it fails to parse, in which case the step’s result is an empty object. Agree a small JSON shape with whoever is going to action these, and say so in the escalation message.
The same message is also available on its own, at $.resume, to any step after the Checkpoint. $.trigger is untouched by the resume and still holds the payload that started the run.
$.resume exists only on a run that was resumed, and it is set whether the run was continued from a pause or retried after an error. On a run that has never been resumed, reading it gives [].
A Condition step after the Checkpoint can then route on it:

​
What it does not do

  • No quorum. Any single Continue resumes the run, however many people were assigned. There is no “2 of 3” or “all approvers”.
  • No timeout. A paused run has no expiry and no automatic approve, reject or escalate. It waits until a person acts or somebody cancels it.
  • No approval buttons. There is no set of named options to choose from — approval is whatever JSON the resumer sends, interpreted by your own Condition step.
  • No structured display. The person sees the task’s title, description and priority. There is no separate data panel showing values from the run; put anything they need to see into the description.

​
Finding paused runs

Monitoring counts paused runs separately and can filter to them. A paused run’s detail panel offers Continue (resume from the paused step) and Rerun (start again from the beginning with a new trigger). Both are also available on a run that has errored.
Editing a flow changes its draft. Publish to make a change take effect. A run already paused resumes on the configuration it was paused with, not on whatever has been published since.

​
Next Steps

Condition Step

Route on the decision that came back

Assistant Step

An assistant can park a run for a person too

Flow Steps Overview

How a run moves between steps

Delay Step

Wait on a clock instead of a person