How to Debug Salesforce Flows (Flow Logs & Analysis)
Debug Salesforce Flows three ways: Flow Builder's Debug mode for testing with chosen inputs, debug logs (FLOW_ELEMENT events) for what actually happened during a real record save alongside triggers and validation, and flow error emails for the failing element. For production behavior — especially record-triggered flows interacting with Apex — the debug log is the source of truth.
Debug mode vs. debug logs
| Flow Builder Debug mode | Debug logs | |
|---|---|---|
| What it shows | Element-by-element path for a simulated run | What actually ran in a real transaction |
| Sees trigger interaction | No | Yes — flows interleaved with Apex, validation, workflow |
| Good for | Building & unit-testing a flow | Diagnosing production incidents and cross-automation bugs |
| Limitation | Simulated context can differ from real saves | Requires trace flag; verbose output |
Reading Flow events in a debug log
Set the Workflow category to FINER and each flow run produces a readable trail:
09:12:44.2 (201400021)|FLOW_START_INTERVIEW|3001x00000AbCdE|Opportunity_After_Save
09:12:44.2 (203100450)|FLOW_ELEMENT_BEGIN|3001x00000AbCdE|FlowDecision|Check_Stage
09:12:44.2 (203900112)|FLOW_ELEMENT_END|3001x00000AbCdE|FlowDecision|Check_Stage
09:12:44.3 (210222040)|FLOW_ELEMENT_ERROR|The flow tried to access a null value...
FLOW_START_INTERVIEW— which flow started (interview = one execution).FLOW_ELEMENT_BEGIN/END— each element as it runs; diff the elapsed counters to time an element.FLOW_BULK_ELEMENT_*— bulkified element execution across many records in one go.FLOW_ELEMENT_ERROR— the failing element and message; the closest thing to a flow stack trace.
Because these events sit in the same log as CODE_UNIT_STARTED trigger events, the log answers the question Debug mode can't: did my flow run before or after my trigger, and who overwrote whose field? That interleaving is exactly what ForceLens's Order of Execution view reconstructs visually — see the debug log analyzer guide.
Record-triggered flows in the order of execution
- System validation → before-save flows → before triggers → validation rules → duplicate rules → record saved (not committed)
- After triggers → assignment/auto-response/workflow rules → escalation rules → after-save flows → entitlement/roll-ups → commit
Rules of thumb that fall out of this: use before-save flows for same-record field updates (no recursion, dramatically faster) and after-save flows only for actions on other records or async work. An after-save flow updating its own record re-runs the entire order of execution — a common source of both bugs and CPU limit errors.
Common Flow errors and their causes
| Error | Usual cause | Fix |
|---|---|---|
| "The flow tried to access a null value" | Get Records found nothing; later element references the empty variable | Decision check on "found = null" after every Get Records |
| Unhandled fault on DML element | Validation rule, required field, or duplicate rule blocked the save | Add fault paths; surface the fault message |
| "Too many SOQL queries: 101" | Get Records inside a loop, or flow + trigger recursion | Query before the loop; see SOQL optimization |
| Apex CPU time limit exceeded | Loops over large collections; stacked automations | Bulk-shaped design; consolidate flows; see CPU guide |
| Flow finishes but data is "wrong" | Another automation ran later and overwrote the value | Read the order of execution in the debug log |
Analyzing Flow structure with ForceLens
Runtime debugging finds what broke; structural review finds what will break. From Flow Builder, one click hands the entire flow to ForceLens, which parses every element, decision, loop and fault path, scores the flow's health, and writes up findings through the lens you pick:
- Developer — null handling, bulkification, DML in loops, fault-path coverage.
- Business Analyst — what the flow actually does in business terms.
- QA — test scenarios and edge cases the branches imply.
- Security — sharing context, data exposure, unsafe assignments.
You get a health score, a ready .docx report, and an AI prompt for deeper analysis with your own key — free, processed locally.
Frequently asked questions
How do I debug a Salesforce Flow?
Use Flow Builder's Debug mode for simulated runs, debug logs (FLOW_ELEMENT events) for real transactions, and flow error emails for failures. For production behavior with triggers involved, the debug log is the source of truth.
Do Flows appear in debug logs?
Yes — with the Workflow category at FINE/FINER you get FLOW_START_INTERVIEW, FLOW_ELEMENT_BEGIN/END, FLOW_BULK_ELEMENT and FLOW_ELEMENT_ERROR events, interleaved with Apex triggers in true execution order.
When do record-triggered flows run in the order of execution?
Before-save flows run early, before the record is written; after-save flows run late, after triggers and workflow, shortly before commit. After-save flows that update their own record re-run the entire order of execution.
What's the most common Flow error?
Null access: a Get Records element finds nothing and a later element references the empty variable. Guard every Get Records with a decision check and put fault paths on DML elements.
Read your next Flow like an expert
Analyze any Flow from Flow Builder in one click — health score, expert findings, and a ready report. Free and local.