Debug runs the flow inside Flow Builder with a details panel showing every element, every variable value, and the outcome each Decision took. Run launches the flow the way a user would, with no instrumentation. Both execute as you, with your permissions, which is why a flow that debugs perfectly still fails for the sales team. Debug also offers rollback, and rollback is narrower than it sounds.
What the two buttons actually do
Run opens the flow in the normal runtime. For a screen flow you get the flow URL and the standard container. No debug panel, no variable inspection, and no way to set input values unless the flow asks for them on a screen.
Debug opens a dialog first. You set input variable values, choose a record for a record-triggered flow, and pick a few options. Then the flow runs with a panel down the right side listing elements in execution order, with the value of every variable after each step. That panel is the reason to use Debug for anything non-trivial.
Debug runs as you, and that is the big one
The interview runs in your session with your profile, your permission sets, your role, and your sharing. If you are a System Administrator, and you almost certainly are, Debug tells you nothing about whether a standard user can do what the flow asks.
This matters most when the flow runs in user context. A Get Records that returns five rows for you returns zero for a user without sharing access, and a zero-row Get Records returns null rather than failing, so the flow completes and does nothing. That is the classic “works for me” flow bug, and no amount of debugging as yourself will surface it — its louder cousin is Attempt to de-reference a null object, thrown the moment something reads a field off that null.
Rollback mode, and what it does not roll back
When debugging a record-triggered flow you can tick the option to roll back changes the debug run makes. The DML the flow performs is undone at the end, so you can debug against production-shaped data without leaving records behind.
Treat that as a convenience, not a guarantee. Rollback covers the database work inside the transaction. It does not cover side effects that leave the transaction:
- Platform events published with the immediate publish behaviour fire regardless, because that is the point of immediate publish.
- Outbound HTTP callouts have already happened. The remote system does not know you rolled back.
- Asynchronous and scheduled paths are queued separately and are not part of your transaction.
- Anything downstream automation did outside the transaction boundary.
If a flow talks to an external system, debug it in a sandbox pointed at a sandbox endpoint. Rollback is not a safety net for integrations.
What Debug cannot reproduce
Debug is a single-record, single-user, best-case run. Production is none of those things.
Bulk. Debug processes one record. A record-triggered flow in real life gets batches of up to 200 from a data load, all sharing one set of governor limits. A Get Records inside a Loop looks fine at one record and blows the SOQL limit at eighty.
Other automation. Debugging a record-triggered flow against an existing record without saving it means nothing else fires. No triggers, no other flows, no validation rules, no roll-up recalculation. The order of execution that actually causes your bug is absent from the test.
Subflow versions. A Subflow element calls the active version of the subflow, even in debug, even when you have the draft open in another tab. If the subflow behaviour looks stale, that is why.
The real container. A screen flow embedded on a record page receives recordId from the page. Run and Debug do not supply that unless you set it manually, and a flow that works in Debug can land on a record page and find its input variable empty.
The user’s error experience. In Debug you see the full fault message and the element that threw. A real user sees a generic unhandled fault message, and the detail goes to an email instead. Build fault paths on the strength of that, not on what Debug shows you.
Frequently asked
Do debug runs create real records? Yes, unless you enabled rollback. A Debug run of a flow that creates a Case creates a Case, in whatever org you are in.
Why is the debug panel empty for part of my flow? Elements on paths that were not taken never execute and never appear. If an element you expected is missing, the branch before it went the other way.
Where do failures go when there is no Debug panel? The fault email goes to the flow’s last modified user by default. You can change the recipient in Process Automation Settings, and you should, because that default means whoever last touched the flow owns its alerts.
