Business Logic and Process Automation · Topic 6 of 7
Maintaining, Monitoring and Troubleshooting Flows
Keep Salesforce flows healthy: versions and activation, debugging, fault paths, flow error emails, paused and failed interviews, trigger order and tests.
- 4 min
- Save changes as a new version; only one version is active.
- Debug in Flow Builder, optionally in rollback mode or as another user.
- Fault paths handle element failures; error emails report unhandled ones.
What it is
After a flow goes live, the app builder keeps it working: changing it safely through versions, testing it with debug and flow tests, handling errors with fault paths, and finding out why a flow failed from error emails and the Paused and Failed Flow Interviews page.
How it works
Versions and activation
- Saving changes as a new version keeps the old one intact.
- Only one version of a flow can be active at a time. Activating a new version deactivates the previous one.
- Running interviews of an old version can finish on that version.
- To roll back, activate an earlier version.
Testing a flow
| Tool | What it does |
|---|---|
| Debug in Flow Builder | Runs the flow and shows each element's path and values; can run as another user |
| Rollback mode | Debug runs without saving record changes |
| Flow tests | Saved tests with set inputs and expected outcomes, for supported flow types such as record-triggered flows |
| Sandbox testing | Test with realistic data before deploying |
Flow tests can be rerun after every change to confirm the flow still behaves correctly without writing code.
Handling errors
- A fault path on a data or action element runs when that element fails. Use it to show a friendly screen, log the error to a record, or notify an administrator.
- Without a fault path, the user sees an unhandled error and the transaction is rolled back.
- Salesforce sends a flow error email describing the failure. In Process Automation Settings, you choose whether it goes to the user who last modified the flow or to the Apex exception email recipients.
Monitoring
| Place | Shows |
|---|---|
| Paused and Failed Flow Interviews | Interviews waiting to resume and those that failed |
| Flow Trigger Explorer | Every record-triggered flow on an object and the order they run in |
| Automation app | A single place to see and manage flows |
| Setup Audit Trail | Who changed or activated a flow |
Several flows on one object
When several record-triggered flows run on the same object and trigger, set a trigger order value on each flow, or view and adjust order in Flow Trigger Explorer. Without it, the order is not guaranteed. Consolidating related logic into fewer flows also helps.
Common causes of failure
| Symptom | Likely cause |
|---|---|
| "Too many SOQL queries" or "Too many DML statements" | Data elements inside a loop |
| Flow fails only for some users | The running user lacks access to a record or field |
| Flow runs repeatedly | Entry conditions fire on every update |
| Flow does nothing | It is inactive, or entry conditions are never met |
Flows can run in user context or system context. Screen flows usually run as the user, so the user's permissions apply; a record-triggered flow normally runs in system context.
A worked example: a record-triggered flow on Case started failing for a batch of 500 imported records with a "Too many SOQL queries" error. Debugging shows a Get Records element inside a loop. The builder moves the Get Records before the loop, stores results in a collection, builds the changes in the loop with assignments, adds one Update Records after the loop, adds a fault path that emails the admin team, and activates the fixed version.
When a question asks how to change an active flow safely, the answer is to save a new version, test it, and then activate it.
How the exam asks about this
- "Find out why a flow failed for a user." The flow error email and debug as that user.
- "Show a message instead of an error when an update fails." A fault path.
- "Control which of three record-triggered flows runs first." Trigger order or Flow Trigger Explorer.
What to remember for the exam
- Save changes as a new version; only one version is active.
- Debug in Flow Builder, optionally in rollback mode or as another user.
- Fault paths handle element failures; error emails report unhandled ones.
- Paused and Failed Flow Interviews shows waiting and failed interviews.
- Set trigger order for several record-triggered flows on one object.
Debugging a flow without rollback mode really creates and changes records. Debug in a sandbox or use rollback mode.
Common mistakes
Editing an active version in place. Save as a new version and test first.
Leaving data elements inside loops. It hits governor limits on bulk changes.
Assuming flows on one object run in a set order. Set trigger order.
Check yourself
How many versions of a flow can be active at once?
Only one.
What does a fault path do?
It runs when an element fails, so the flow can handle the error instead of showing an unhandled fault.
Where can an admin see the run order of record-triggered flows on an object?
In Flow Trigger Explorer.
Topic 6 of 7 in Business Logic and Process Automation
Test yourself on Business Logic and Process Automation
The full Salesforce Platform App Builder question bank has 648 questions, with timed practice exams and an explanation for every answer.
This study guide is independent and is not affiliated with, endorsed by, or sponsored by Salesforce. Vendor names, certification names and exam codes are trademarks of their respective owners and are used for identification only.