How a run ends
A Workflow declares the ways a run can end and what each one produces. Getting this right is what lets your team read and report on the work.
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. Declaring dispositions gives every run a conclusion your team can sort and report on.
One disposition per run. The Workflow declares every way a run can conclude, and each run ends as exactly one of them.
The section shows the values as chips under Finishes as. The agent picks one value when the run finishes.
A disposition never stops a run for a person. Where a person must decide, add a human.request step to the Workflow, or have an agent step call sdk.human.ask(). The Work item then waits as Blocked until someone answers, and the run resumes with the answer or ends the way the step says.
So an AP Workflow might end as Matched, Paid, Amount mismatch, Vendor not found, or Duplicate suspected, and ask a person with a human.request step before it pays an invoice whose amount does not match.
Review Required is retired. A new Workflow cannot declare Review Required as a
disposition or mark dispositions for review. The platform refuses the Workflow and points
you to a human.request step or sdk.human.ask(). A Workflow that already declares it
keeps it as an ordinary label.
Mark good and bad results
A Workflow can give each disposition a tone: good, bad, or neither.
The tone colors the disposition's mark wherever the result appears: the chips under Finishes as, the Work items rail, the work item's header, and the work item certificate.
A good result takes the success color, a bad result takes the error color, and a result that is neither stays neutral.
So when you mark Vendor not found as bad, those invoices stand out from the Paid ones, even though both runs completed.
Only a run that completed takes its disposition's tone. A failed, blocked, or cancelled run keeps the color of its status, and a disposition with no tone does too.
When a Workflow declares no tones, the section shows "Every result shows in the same color." next to Colors. Click Mark good and bad results and the composer opens seeded with a request to mark which ways the Workflow can finish are good results and which are bad ones. Send it, and the agent lists the values and asks you which are good, which are bad, and which are neither, rather than guessing from their names. To change one tone later, ask the agent in chat; it changes that value's tone and keeps the others.
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 · blocked · 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.
The app labels a succeeded run Completed, and the work item's header names the disposition beside it, for example Completed: Amount mismatch. The mark takes the disposition's tone, so a completed run with a bad result reads as one.
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.
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.