Workflow run statuses
A workflow run (a flow execution) carries a single status describing where it is in its lifecycle. This page defines the five run statuses, how they transition, and which are terminal. These are distinct from work item statuses — do not conflate the two vocabularies.
The status values come from the released API contract (FlowExecutionStatus) and are surfaced in the builder's run history. See Flow executions for the API and Run history for the UI.
The five run statuses
Status (FlowExecutionStatus) | Terminal? | Meaning | Run-history badge |
|---|---|---|---|
PENDING | No | The run has been accepted but has not started executing yet. | In-progress state |
RUNNING | No | The run is actively executing its nodes. | Running (in-progress) |
COMPLETED | Yes | The run finished its configured path successfully. | Completed (green) |
FAILED | Yes | The run stopped on an error before completing. | Failed (red) |
CANCELLED | Yes | The run was stopped before it completed. | — |
Typical transitions
A run normally moves forward through these states; it does not move backward.
Code
- A run is created in
PENDING, then begins executing asRUNNING. - From
RUNNINGit ends in exactly one terminal state:COMPLETEDon success,FAILEDon error, orCANCELLEDif it was stopped. - A run that has reached a terminal state does not change status afterward.
Terminal versus non-terminal
- Non-terminal:
PENDING,RUNNING. The run is still in flight; itscompletedAtis not yet set. - Terminal:
COMPLETED,FAILED,CANCELLED. The run is finished and its outcome is fixed.
UI and API naming
The API uses the uppercase enum values above. The run-history UI shows them as title-cased, colored badges — for example, COMPLETED displays as Completed (green), FAILED as Failed (red), and an in-progress run as Running.
Note the spelling: the run status is CANCELLED (double "L"). The work item status uses the American spelling CANCELED (single "L"). They belong to different vocabularies — see Work item statuses.
No retry or replay is implied by status
A run's status records what happened; it does not imply any automatic retry. There is no mechanism that moves a FAILED run back to RUNNING. To re-process a case, you start a new run, or — through the API only — use rerun, which creates a new execution (with its own status and executionId) from the original inputs and repeats any side effects. Reruns and run comparison are not features of the Monitor & Review UI.
Where to go next
- Flow executions — the API resource, where
statusis returned. - Run history — browse and inspect runs in the builder.
- Work item statuses — the separate eight-status vocabulary for work items.
- Concepts glossary — concise definitions for every term.