Monitoring Flow Runs
Flow Run monitoring helps your team understand what happened when a Flow ran, where it succeeded, and where it needs attention.
Use this guide when you need to review a workflow after launch, investigate a failed path, or understand why a case did not behave the way you expected.
What a Flow Run shows
A Flow Run is a record of one execution of a Flow.
It helps you answer questions like:
- Did the Flow complete?
- Which steps ran?
- Where did the path branch?
- Did a step fail, wait, or stop early?
This is one of the most useful places to debug workflow behavior without guessing.
Where to find Flow Runs
Open Monitor and go to the Flow Run area for the workflow you want to review.
Start with the runs that matter most:
- Recent failures
- Unexpected handoffs
- High-volume workflows
- Customer cases the team flagged manually
How to read a Flow Run
Start with the high-level status first, then move into the details.
Look for:
- Whether the run completed
- When it started
- Which path it followed
- Which step was last reached
This gives you a fast answer to whether the problem was broad, local, or expected behavior.
How to inspect step details
Each step in a run can help explain what happened next.
Use step details to understand:
- What information entered the step
- What the step produced
- Whether the step waited, completed, or failed
- Whether later steps received the right context
When a Flow behaves strangely, the problem is often not the last step you see. It is usually an earlier step that gave the wrong context, took the wrong branch, or never completed.
Recognizing successful, partial, and failed runs
Successful run
The Flow reached the expected end state and the output matched the intended path.
Partial run
The Flow ran, but only part of the intended path completed. This can happen if a condition was not met, an external dependency was missing, or the workflow stopped early by design.
Failed run
The Flow hit a blocking issue that prevented the path from finishing.
Common patterns to investigate
Condition mismatch
The Flow took a different path than expected because the case did not meet the right conditions.
Missing or weak input
The Flow did not have the details it needed to continue cleanly.
External dependency delay
The Flow depended on a connected system that responded slowly or not at all.
Source material problem
A downstream step behaved poorly because the supporting Data or Knowledge was out of date or incomplete.
How to debug stuck or confusing runs
Use this order:
- Confirm the expected outcome for the run.
- Identify the last step that behaved as expected.
- Inspect the next step where behavior changed.
- Decide whether the issue was routing, workflow logic, external context, or stale supporting material.
This keeps the review focused instead of jumping between several possible causes at once.
Best practices
- Review failed and high-impact runs on a regular cadence.
- Use real examples from support, not only test cases.
- Re-test after changing a Flow that had production issues.
- Review connected sources when a workflow depends on current reference material.