The Run History
Every execution is recorded as a run, and every node it reached as a step.
Where to find it
Architect Panel → Automation:
- Workflow Builder — the canvas, nodes and edges
- Worklist — what is waiting on a person
What a run records
The workflow, the record, its status, which node it is at, how many steps it has taken, what it is waiting for and until when, its context, and when it started and finished.
What a step records
Which node, its status, a detail, and when. So the run history is a readable account: this happened, then this, then it branched here, then it waited.
It answers the question people ask
"Why did this customer get that e-mail" or "why was this not escalated" is answered by opening the run for that record and reading. That is much better than reasoning about the canvas.
Status tells you where a run is
- Running — in progress.
- Waiting — suspended at a wait, timer or approval, with its resume time recorded.
- Finished — completed.
A population of runs stuck at waiting is the signature of a resume task that is not running.
Steps taken is a health signal
A run with an unusually high step count has probably looped. The count is bounded, so it will stop — but the count itself is what tells you the graph has a cycle.
Look for runs that ended early
A run finishing after two steps in a nine-node workflow ended somewhere it should not have — almost always an unconnected condition port. Comparing step counts across runs finds those quickly.
Read it before changing the canvas
When a workflow is misbehaving, the run history says what actually happened. Changing the canvas based on what you think it does, without reading a real run, is how a second bug is added to the first.
Use it as evidence
For a complaint, an audit or a dispute, the run history is a record of what the system did and when. That is worth more than a description of what it was supposed to do.
It grows
A run and several steps per record. On a high-volume datastore that accumulates quickly, so include it in whatever retention thinking covers your other logs.
Worked example
A customer asked why they had not been contacted. The run for their case showed it had reached the condition after the acknowledgement and taken the false branch, which had no edge. The workflow was corrected and the affected cases identified from their step counts.
Recommendations
- Read a real run before changing the canvas.
- Compare step counts to find runs that ended early.
- Waiting runs piling up means the resume task.
- Include run history in your retention planning.