How a run ends
A Workflow declares the ways a run can end and what each one produces. Getting this right is what decides which work reaches a person and which work does not.
Audience: builders
This page covers the last two sections of a Workflow, Ends as and Creates. For the page as a whole, see Workflows.
Ends as: the dispositions
The section only appears once a Workflow declares one. A Workflow with no disposition runs, produces its outputs, and is done. Nothing it produces can route to a person, because it has no way to say that something needs one. Declaring dispositions is the step that turns output into triage.
One disposition per run. The Workflow declares every way a run can conclude, and each run ends as exactly one of them.
This is where you decide the shape of the work. The section shows the endings in two groups, and the groups cannot overlap:
- Endings the Workflow settles by itself. Shown as chips. The run concluded and nothing needs a person.
- Endings that stop for a person. Shown under "Stops for a person when…". The run still concluded, but this outcome routes the work item to a human.
The agent picks the value either way. What a handover value changes is what happens next: the runtime ranks that work item as needing review and it waits in the inbox for someone to pick up.
So the design question for a Workflow is not "what can go wrong" but "which endings am I willing to let through". An AP Workflow might settle Matched and Paid on its own, and stop for a person on Amount mismatch, Vendor not found, and Duplicate suspected.
Review Required always stops. That value routes to a person whatever the rest of
the mapping says, so a Workflow can declare it without listing it as a handover value.
Disposition is not run status
These two are easy to confuse and they answer different questions.
| What it answers | Values | |
|---|---|---|
| Status | Did the machinery run? | queued · running · succeeded · failed · cancelled |
| Disposition | What did the run conclude? | Whatever the Workflow declared under Ends as |
A run that succeeded has not necessarily been approved. It means the steps executed and the outputs came back. Its disposition might still be Amount mismatch, sitting in someone's inbox.
A run that failed may have no disposition at all, because it never got far enough to reach one. That is an operational problem for whoever owns the Workflow, not a decision waiting for a reviewer.
Do not build reporting on status alone. "95% succeeded" says the Workflow is healthy; it says nothing about how much of that work a person still had to touch. The number your team cares about is usually how many runs settled on their own versus how many stopped for a person.
Creates: the outputs
Every work item carries the outputs the Workflow declares. Each one has a key, a label, and a kind:
| Kind | What it holds |
|---|---|
verdict | A decision, usually from a fixed set of values |
table | Rows and columns |
list | An ordered set of values |
markdown | Written prose, such as a drafted reply |
file | A produced document |
json | Structured data that does not fit the shapes above |
The review surface on a work item renders one tab per output, so the shape you declare is the shape your reviewers get. One of these outputs is the one carrying the disposition.
When a run lands, the platform checks the outputs against what was declared. The work item shows where that got to: not configured, pending, valid, repairing, or failed.
Changing what a Workflow declares
A Workflow is live in its Project as soon as your change is applied, so a change takes effect on the next run.
Safe: adding an optional input, adding an output, adding a new disposition value, rewording a label.
Breaking: adding a required input (triggers that do not supply it start failing), making an optional input required, removing or renaming an output, removing a disposition value that work items already ended as.
Moving a value between the two groups changes your team's workload. Promoting
Duplicate suspected from settled to a handover value sends every future match to the
inbox. Demoting one stops a class of work reaching anybody. Neither shows up as an
error, so decide it deliberately.
Work items that completed under earlier declarations keep the outputs they produced. Prefer adding over renaming when the change is cosmetic.
Rerunning
Rerunning a work item puts it back on the queue against the Workflow as it stands now, so it produces outputs and a disposition under the current declarations, not the ones in force when it first ran.