Reading a Workflow Run
When a workflow ran but stopped halfway, open the run to see what happened at each step, with its input, output and why it failed, retry or cancel it, and go back to fix the automation rule that started it.
A workflow run is the record of one execution: which steps ran, what each one was given, what it returned, and where it stopped.
When you’d use this
- An automation should have done something and you cannot tell whether it did.
- A run failed and you need the actual error, not a guess.
- A run is waiting and you want to know who it is waiting on.
- The automation ran correctly but on the wrong trigger, and you want to fix the rule.
Finding a run
Sidebar → Automation → Overview lists recent runs. Click one.
You can also reach it from Recent Runs on a workflow’s definition page. Runs are visible to anyone with permission to view workflow execution.
What a run page shows
The page is titled after the document the run was about, or the workflow’s name.
Status is one of: active, waiting, waiting human, paused, completed, failed, cancelled or timeout. Alongside it: the current state the run is sitting in, and its service-level indicator.
Workflow map draws the definition with this run’s path overlaid, so you can see where it got to.
Below that, each step lists its input, its output, and - when it failed - why. A step waiting on a person reads “Waiting on <name> · assigned <duration>”, which answers the most common question about a stuck run in one line.
Open in editor jumps to the builder with this version pinned, so you are looking at exactly the definition that ran rather than the latest draft.
Acting on a run
| Control | When it is available |
|---|---|
| Retry | Only on a failed run. Otherwise it says “This run is not failed; nothing to retry.” |
| Cancel Workflow | While it is still going. Confirms first |
| Pause and resume | While it is active |
| Advance Workflow | To push a run past a step by hand. Confirms first |
Advancing a run by hand is deliberate interference with an automation. Use it to unblock something, not as a routine step.
Editing the rule that started it
Most automations are a when/if/then rule rather than a hand-drawn graph. To change one:
- Go to Sidebar → Automation → Workflow Catalog.
- Find the automation and open its edit action.
- The page opens on Edit Automation with three numbered sections:
- WHEN this happens… - the trigger
- IF - the conditions that narrow when it runs
- THEN - the actions it takes
- The right-hand rail shows the same effect summary the publish gate checks, so you can see what your edit changes before you save.
- Click Save draft, then go through Test, then review to publish it.
Editing automations needs permission to manage workflow definitions.
What can trigger a rule
The triggers offered depend on which modules you have:
| Trigger | When it fires |
|---|---|
| Document Event | A document is created, updated, has data extracted, or changes status |
| Scheduled | On a schedule - daily, weekly, or a custom cron expression with a timezone |
| Webhook | An external system calls a URL you configure |
| Manual | Only when somebody clicks the trigger button |
| Form Submission | A form is submitted, changes status, or moves to a stage |
| Payment Event | A payment event occurs |
| WhatsApp Message | A WhatsApp message arrives |
| Communication Event | A communication event occurs |
| Support Ticket Event | A support ticket event occurs |
| Anomaly Detected | Second Pair of Eyes flags an anomaly |
| Agent Finding | An agent raises a finding |
| Class Event | A class event occurs |
For a schedule you can pick a preset - Every weekday at 9am, Every Monday at 9am, Every day at 8am, First of every month - or write your own cron expression.
A manual automation says so plainly: it only runs when you trigger it from the automations list.
What it affects
- Retrying a run executes the remaining steps for real, with real side effects. It is not a simulation.
- Cancelling stops the run. Anything it already did stays done.
- Publishing an edited rule changes what happens on every future trigger. Runs already in flight finish on the version they started on.
- Advancing a run by hand records who advanced it in the transition history.
When it goes wrong
| What you see | Why | What to do |
|---|---|---|
| “Workflow instance not found.” | The run belongs to another organization, or was deleted | Go back to Automation → Overview and find it in the list |
| Status waiting human with “Waiting - unassigned” | A person step has no assignee | Open the definition and give that step an owner, then advance or restart |
| “This run is not failed; nothing to retry.” | Retry only applies to failed runs | Cancel it instead, or advance it past the step |
| “Could not save this automation.” | The save was refused | Read the message, fix the field, save again |
| “Name is required” / “At least one action is required” | The rule is incomplete | Fill in the missing part |
| “Choose the status that fires this automation” | A status-change trigger has no status chosen | Pick the status in the WHEN section |
| “Couldn’t load trigger types. Please refresh the page and try again.” | The trigger catalog did not load | Reload the page |
| A Failed step with an empty output | The step errored before producing anything | Read the error on that step; it names the cause |
Next step
- Building Workflows - the builder, the review gate and publishing.
- Build with AI from a document - turn a written procedure into a draft.
- Task Management - where a workflow’s person steps land.