Workflow Pauses
Set up human checkpoints, read pending actions, understand pause states, and confirm resume or cancellation outcomes.
A Pause block creates a Workflow Pause, which is a human-in-the-loop checkpoint. A pause lets a run record a message and stop at a specific node. The run then waits for a decision before Eigenn tries later work.
Prerequisites
- Use a Starter or higher workspace.
- Use a workspace owner for the supported Workflows navigation and write actions.
- Deploy a workflow that contains a configured Pause block.
- Make the checkpoint message specific enough for a reviewer to make a safe decision.
Wait and Pause Are Different
| Block | Purpose | How it continues |
|---|---|---|
| Wait | Delay execution by minutes, hours, or days from policy start, invoice due date, or the previous step. | A scheduled resume runs after the calculated time. |
| Pause | Stop for human review. Create a checkpoint record. | Eigenn must queue a resume request. The configured timeout can also make the run eligible for scheduled continuation. |
Both can put an execution in Waiting. Always examine the current node.
Configure a Pause Block
In Workflow Studio, add Pause. Select it. Then open Editor.
- Message is the context displayed to the reviewer.
- Resume Key is an optional key used by the worker resume endpoint.
- Timeout (seconds) is optional. When you give a value, it must be at least 60 seconds.
Leave Resume Key empty for ordinary web-managed checkpoints. The worker then generates a unique UUID for each pause. A configured fixed key is unique at the database level. If you use the same value across many executions, the run can resolve to an earlier checkpoint. It then does not create a new checkpoint.
Connect the Pause block to the next block. Save the workflow. Check the workflow. Then deploy the workflow.
Open Workflow Pauses
The Workflows section has only Workflows and Executions tabs. To open the pause dashboard:
- Open Workflows → Executions.
- Select a run with the Waiting state.
- Choose View All Pauses in Action Required.
You can also act on a pending pause directly from Action Required in Execution Details.
Read the Dashboard
The summary cards are:
- Pending Action from an exact pending-count query,
- Resumed from up to 100 resumed records,
- Expired from up to 100 expired records, and
- Total from up to 100 records of any state.
The All Pauses list loads up to 50 records by default. The list puts pending records first, then newer records. Use Search pauses... to match node ID, message, execution ID, or workflow-definition ID. Use All Statuses to choose Pending, Resumed, Expired, or Canceled.
These cards and lists are operational summaries, not an unlimited audit export.
Pause States
| State | Description |
|---|---|
| Awaiting Action / Pending | The checkpoint record can accept a resume or cancel action. |
| Resumed | Eigenn marked the checkpoint record resumed. Confirm the execution separately. |
| Expired | The worker resume endpoint found that the configured expiry passed. |
| Canceled | Someone canceled the checkpoint record. This alone does not cancel the execution. |
The card can show an Expires timestamp. Treat the timestamp and execution state as separate facts from the badge.
Review Pause Details
Select a card or choose Resume to open Pause Details. The modal includes:
- status and expiry,
- workflow-definition ID,
- execution ID,
- node ID,
- resume key,
- created and resumed timestamps, and
- the checkpoint message.
For pending checkpoints, Resume Payload (Optional) accepts a JSON object. The browser rejects invalid JSON.
Example:
{
"approved": true,
"notes": "Approved after invoice review"
}Do not enter secrets. Runtime context can appear as raw JSON on the execution page.
Current Web Resume Behavior
The current Resume Workflow web action:
- needs the checkpoint to still have status
pending, - marks the checkpoint
resumed, and - records the resumed timestamp.
It now does not enqueue the worker resume job. It accepts the optional payload. It does not persist or merge that payload. The separate worker resume endpoint does enqueue continuation and merge payload. The current web modal is not connected to that operation.
For that reason, the success toast Workflow resumed successfully proves that the checkpoint update succeeded. It does not prove that the execution continued.
After you choose Resume Workflow:
- Return to Execution Details.
- Refresh the page.
- Confirm the execution moves from Waiting to Running or Completed.
- Confirm a resumed step appears in Execution Replay.
- If the run stays in the Waiting state, preserve the execution ID and the resume key.
- Contact support or a self-hosted operator who can use the worker resume endpoint.
Current Timeout Behavior
The Pause editor describes timeout as auto-expiration. In the current engine, the timeout also becomes the execution’s scheduled resume time. The sweep for runs in the Waiting state runs every two minutes. It can enqueue continuation after that time. The resume job then marks pending records Resumed.
By contrast, the worker resume endpoint marks a checkpoint Expired when someone calls it after the expiry. The current web action does not do that expiry check.
A passed wall-clock expiry does not guarantee that the dashboard already says Expired. Check the execution’s current state and replay before you decide whether work is still blocked.
Cancel a Pause
Choose Cancel Pause only when you want to close the checkpoint record itself. The action changes a pending pause to Canceled.
It does not:
- cancel the execution,
- advance the execution to the next block, or
- create a replacement run.
If the execution must stop, use Stop while the editor tracks that run. You can also use an authorized execution-cancel integration. If the execution must continue, resolve the resume path. Do not cancel the checkpoint.
Idempotency and Concurrency
- A generated resume key is unique per checkpoint.
- For an already-resumed, expired, or canceled checkpoint, the worker resume endpoint returns a terminal response. It does not queue a second resume.
- The web action rejects any checkpoint that is no longer pending.
- The worker resume job row-locks the execution and skips a run that is no longer resumable.
- A run in the Waiting state will not resume while its workflow definition is inactive.
Troubleshoot
Resume Payload says invalid JSON
Enter one JSON object with quoted property names. The current form contract does not accept arrays, comments, or a comma at the end.
Resume succeeded but the execution is still Waiting
This matches the current gap in the web connection. Refresh Execution Details. Then escalate with the execution ID, node ID, and resume key. Do not click Resume again. The pause is no longer pending.
Cancel Pause did not cancel the run
A checkpoint cancellation and an execution cancellation are different operations. The current pause button only changes the checkpoint record.
A pause shows Expires in the past but still says Awaiting Action
Eigenn persists the status. The browser does not derive it from the current clock. Refresh the page. Then examine the execution. The resume endpoint, scheduled continuation, and current web action handle expiry differently.
The pause did not produce a new card
Check that the workflow was active. Check that the execution reached the Pause node. Check that you did not use the Resume Key again. Open the run’s replay to confirm the current node.
Eigenn skipped the resume after a deactivation
A resume job needs the workflow definition to remain active. Examine the current definition and the execution in the Waiting state first. Then reactivate the workflow. Major node or edge changes can make continuation unsafe.