Workflow runs
Run history shows what happened to an individual customer journey. Each trigger creates a run that follows the published workflow, recording the steps it reaches and where it completes or fails. Use that evidence to investigate an unexpected outcome.
The Runs tab is where you go when an automation did not do what you expected.
Open the Runs tab
Open the workflow and choose Runs, next to Composer at the top. The tab only appears once the workflow has been published at least once, since there is nothing to run before that.
A panel beside the canvas lists the most recent runs, newest first, each showing when it started and how it ended:
| What you see | What it means |
|---|---|
| In progress | The run has not completed. It may be executing, on a Delay, paused with its workflow, or waiting for credits or capacity. |
| Finished! | It reached the end with nothing failing. |
| Failed. | A step failed and the run stopped there. |
| Needs attention | Execution has a recovery reason and does not continue automatically. Inspect the reason and accepted effects. |
Use Terminate run in the selected run's details to end that run, its children and pending continuations. You need workspace write permission. To contain all journeys, pause the workflow; to stop enrollment while existing runs finish, use Stop new runs. Completed effects remain, and an external request already in flight can still complete. See workflow controls.
Select a run and the canvas redraws it: the steps it went through are outlined in green, the step it is sitting on right now in the accent colour, and a failed step in red. The connection points along the path it took are highlighted, so a branching workflow shows you at a glance which way this particular run went.
The Workflow run details panel in the corner gives you when the version was published, when the run was triggered, how many steps it went through, and either its status or when it finished.
Read all of the history
History is paginated. Visible history identifies the step range currently loaded, and the graph highlights that page. Earlier steps loads preceding evidence; Latest steps returns to the newest page. A path outside the visible range is not evidence that those earlier steps never ran.
Steps is the run's recorded execution count. Emails in visible history counts email records only in the loaded page. Once all history is visible, the label is Emails created. An email record count does not establish provider acceptance or delivery; open its activity.
Branched from links a child to its parent and the parent step that split it. Use that relationship before counting apparent duplicates. A root with three matching records can deliberately create three children, each executing later steps separately.
See what a step did
Click any step on the canvas and its history opens underneath it:
- Entered at and Left at, and how long it Took.
- Received and Produced: the values the step was handed, and the values it added, each listed by name with a short summary.
- For a Send Email step, the Email status and a View email details button, which opens the message itself along with its Activity: sent, delivered, opened, clicked, bounced, unsubscribed.
- The failure reason, in red, if the run stopped there.
Compare Received and Produced to the decision you expected. An empty lookup may be a valid result; a controller may pass existing values on without adding a new one. Trace the recipient and the relevant purchase, event or object back through the path before treating a missing output as a failure.
Distinguish live values and saved evidence
Publishing freezes configuration, not every future customer fact. Ordinary record references can be read when a later step needs them. On-demand evaluated attributes execute saved lookup logic. Scheduled evaluated attributes read complete published calculations, with generations that can be pinned for the execution.
Query output describes the lookup made at that step. An accepted AI decision, event-history decision and loop input can be retained for recovery. The Evaluated attribute threshold trigger supplies the exact previous and current values that caused enrollment. Compare those snapshots with their time and generation; today's profile can differ without making the original crossing wrong.
Source-record deletion can remove private run payloads and history while preserving run identity, lineage and financial receipts. Missing old values after that cleanup are not permission to reconstruct them from a newer profile or replay the old action.
When a run fails
A terminal step failure ends that run. There is no general replay-from-this-step control. Temporary waits and safe infrastructure retries are different from terminal failures: check the recorded reason before deciding that a customer was skipped.
The failed step is outlined in red and shows the failure message right on the canvas, without needing to select it. Common ones:
| Message | What to do |
|---|---|
| The recipient email address is suppressed. | The address bounced, complained or unsubscribed. Nothing to fix in the workflow. |
| Insufficient credits while execution is waiting | Restore available credits. Waiting execution can continue; do not re-trigger it and create a second journey. A run already marked Failed needs investigation. |
| An HTTP Request failure or Needs attention | Check URL, headers, payload, response shape and the receiving system. A timeout or response-validation failure may happen after the external system acted. Reconcile before triggering another call. |
| No available emails, an unverified sender domain or disabled sending | Correct the sending prerequisite. Email allowance exhaustion is distinct from a credit wait. |
| Email acceptance or AI/tool outcome is unknown | Inspect the recorded recovery reason and provider or external activity. The run does not blindly repeat uncertain work. |
If the failure is in the workflow, fix the draft and publish. New triggers use that corrected version; existing runs keep their original one. Publishing also unpauses the workflow, so check older waiting runs before releasing them.
Waits and safe recovery
Long delays persist their wake-up time and survive restarts. Credit shortage and concurrency limits park work for another attempt rather than failing the run. Temporary service-capacity or explicitly retryable delivery responses can also wait.
The runtime records completed step effects and charges so a safe recovery can reuse them. That does not guarantee every external action is safe to repeat. An HTTP call, email or AI/tool execution with an uncertain outcome can require attention rather than being blindly repeated. Automatic infrastructure retries are bounded; exhausting them is a reason to inspect the run.
Inspect Needs attention
The details show Needs attention, Stopped at and the recovery reason. The run does not continue automatically. Topping up credits, refreshing the page or publishing another version does not establish that the held action is safe to repeat.
Check the action's destination: email activity for Send Email, the receiving system for HTTP Request, and tool or model evidence for AI. Find whether the action was accepted and whether it already changed anything. Retain that evidence with the run when deciding the next customer action.
If the old journey should end, use Terminate run. There is no general skip, rewind or replay-from-this-step control. A replacement run is new execution: it can repeat writes, sends and paid generation. Define its scope from the remaining work rather than replaying the entire journey because an earlier result is unclear.
Terminate a run
Select the run and click Terminate run under Run control, then confirm. This ends the selected run, descendants and pending continuations. Other roots in the same workflow are unaffected, and new triggers can continue unless you stop enrollment or pause the workflow.
An explicit termination at a current step is recorded as a failure reason. Accepted external effects and incurred charges remain. A termination of the parent includes children created by Find Records or For Each, so inspect the lineage before using it.
If a step is committing, the server asks you to retry after it finishes. If one termination cannot settle the descendant tree, terminate child runs first and retry the parent. A rejected termination is not a completed stop; reopen the details and check its state.
For a faulty reminder, first contain ongoing execution, then identify every root and child affected by the wrong lookup. Terminate the journeys that must not proceed on that version, correct the draft and verify a controlled example. Publishing the correction can resume surviving old runs, so review them before publication.
Why one trigger produced several runs
Two things split a run into many:
- A Find Records, Create or Update Records or Delete Records step with Process each record separately checked. Each record carries on as its own independent run, with its own history.
- A For Each step, which always splits, one run per item in the list.
Each split is a real child run with its own subsequent step execution and cost. Child runs retain their parent relationship, which helps distinguish intentional fan-out from duplicate triggering. Count executed steps across the children when estimating usage, not only the number of boxes on the canvas.
Which version a run is on
Publishing takes a frozen copy of the workflow. A run stays on the copy it started with and finishes on it, even if you publish three more times in the meantime. Only new triggers pick up the latest version.
That is why the canvas you see in the Runs tab can differ from the one in the Composer. It is showing the workflow as it was when that run began. See Manage workflows.
Measure across all the runs
The Metrics tab answers the volume questions rather than the single-run ones. It shows the success rate, total runs, and how many completed, failed and are still waiting, all for one published version, which you pick from the Versions list in the same side panel.
Where the river leaks ranks the steps losing the most runs. Click one and the canvas jumps to it. That is the shortest route from "this automation underperforms" to the step responsible.
Read runs from your own code
The API lists runs and retrieves a run's status, step count and paginated history, including parent information for child runs. It does not return the live values the run carries. See the workflows API reference.
Related
- Workflows: steps, triggers, and how a run flows.
- Manage workflows: publishing, pausing, versions.
- Workflow billing: what each run costs, and the cap on runs at once.