Runs and results
See how often one workflow started, what each run did step by step, which steps failed, and which starts were held back.
Overview
Every workflow page has two views: Editor, where you build it, and Runs, where you see what it actually did. Open a workflow from Brand → (your brand) → Workflows and switch to Runs. Everything on it is about that one workflow. The permission is Workflows.
The figures cover the workflow in the chat widget, on Facebook and Instagram, and in email conversations. Runs during phone calls are not recorded — they appear neither in the chart, nor in the tables, nor in the Sessions column.
Choosing the Period
How Often It Started
Workflow triggers
The chart at the top shows the total number of starts in the period, and a line of how they were spread over the days. Hover a point for the exact count and date.
The Runs Table
Every run of the period, newest first:
| Column | What it shows |
|---|---|
| Started | When the run began |
| Started by | What started it: the trigger's name (for example User says), Started from the inbox (a colleague started it by hand), Started by the visitor (a Home button, a conversation starter, an Engagement banner or chat message, a link or your website's code), or Started by another workflow |
| State | Running, Waiting for an answer or Finished |
| Ended as | What ended the run when it was not the normal finish: handed over to another workflow, replaced by a newer run, stopped because the workflow was edited, the workflow was switched off, or, in red, could not start the next workflow and stopped by an error. A run that simply finished (or is still going) shows a dash |
| Steps | How many steps the run recorded |
| Failed steps | How many of them failed, as a red badge |
Filter the table by State, Started by and Ended as. A period shows at most its newest 1,000 runs; a line under the table says so when there were more.
Opening a Run
Click the arrow at the start of a row to see what the run did:
- Recorded steps, in the order they ran — each with its step type, its text as it was when the run happened, and the time.
- What a step recorded — the visitor's answer, shown as Saved as and the value's name when the step names it.
- The branch it took — which button the visitor pressed, which condition matched (or that the run took the "otherwise" branch), and whether a Call an API step went on as Worked or Failed.
- What an API call did — the status the API answered, how long it took and how many attempts it made. When something went wrong you also see the reason (timed out, error status, could not be reached…), the mapped values that found nothing at their path, and the first part of the reply, which is kept only when the call had trouble.
- A Start a workflow step that could not start the next workflow says which one, and why.
- Values collected — every value the run had, each marked with where it came from: the trigger, the visitor, an answer, an event, the API, or handed down from the workflow that started this one.
Each row also has an Open the conversation link, which takes you to the conversation in the inbox. It is shown only to members who also have the Inbox permission.
Starts Held Back
The second table, Starts held back, lists the moments when the trigger matched but a rule kept the workflow quiet. Each line has the time, the trigger and the reason, written out in full — for example a colleague was in the conversation, the visitor had already written, the trigger's filter did not match, another workflow with a higher priority number won, the channel cannot run this workflow, or the visitor is blocked. Filter it by Reason and Trigger. A start held back only because the workflow already ran as often as How often allows is not listed: for a greeting that runs once per visitor that is every returning visitor, and those lines would bury the ones that explain something.
Held-back starts are kept for 30 days, so this table never reaches further back than that, whatever period you pick. Nothing is recorded when the AI simply did not pick a User says workflow — that is a normal answer, not a held-back start.
Failed Steps
Two kinds of step count as failed:
- a Call an API step whose call failed — including a call it skipped because the step had reached its limit (the run shows limit reached — not called) — and
- a Start a workflow step that could not start the workflow it names — for example it was switched off or deleted, belongs to another brand, or the workflows start each other in a loop.
When a step of a workflow failed in the last 24 hours, you see it in two places: a red badge such as 2 failed steps beside the workflow on the brand's Workflows list (click it to open the Runs view), and an alert at the top of the Runs view. In the conversation itself, the visitor got an apology and your team was asked to take over — unless you drew a Failed branch from the API step, in which case the workflow did what that branch says.