Debugging Flows and Flow Error Emails

Why This Topic Matters

Flow Builder is the primary declarative automation tool in Salesforce, and the Advanced Administrator exam expects you to go beyond simply building flows. You must know how to troubleshoot them when they fail, interpret the diagnostic information Salesforce provides, and configure how and to whom error notifications are delivered. In the real world, a broken flow can block record saves, silently skip business logic, or frustrate hundreds of users at once. The exam tests whether you can identify the cause of an error quickly, choose the right debugging tool for the situation, and set up your org so that the right people are alerted when something goes wrong. Questions in the Advanced Process Automation domain frequently present a scenario where a flow fails and ask you to pick the most efficient diagnostic step or the correct configuration change.

What Are Flow Debugging and Flow Error Emails?

Flow debugging refers to the set of tools and techniques used to trace a flow's execution path, inspect variable values at each step, and locate the element where a failure occurs. The main debugging tools are:

1. Debug in Flow Builder – A built-in mode that runs the flow with test inputs and shows a step-by-step execution log in the canvas.
2. Debug Logs – Apex-style logs captured via Setup for a specific user, which include FLOW_ELEMENT and related events when the Workflow log category is set appropriately.
3. Fault Paths (Fault Connectors) – Connectors you draw from data elements (Get, Create, Update, Delete) and action elements to a handler that runs when the element fails.
4. Paused and Failed Flow Interviews – A Setup page listing interviews that are waiting or have errored.
5. Flow Error Emails – Automatic emails Salesforce sends when an unhandled fault occurs in a flow.

Flow error emails are the notifications Salesforce generates when a flow interview fails and no fault path handles the error. The email includes the flow name, version, the element where the error occurred, the error message, the running user, and the values of variables at the time of failure. These emails are controlled by an org-wide setting in Process Automation Settings.

How Flow Error Emails Work

Navigate to Setup, then Process Automation Settings. The option Send Process or Flow Error Email to has two choices:

• User Who Last Modified the Process or Flow (the default) – The error email goes to whoever last saved the active flow version.
• Apex Exception Email Recipients – The email goes to the users and external addresses listed on the Apex Exception Email page in Setup. This option is strongly recommended for production orgs so that a stable admin or IT distribution list receives notifications, rather than a developer who may have left the company.

Key facts to remember:
• The setting is org-wide; you cannot configure different recipients per flow through this setting.
• The email is sent only when the error is unhandled. If a fault connector catches the error, no error email is sent unless you explicitly build an email action into the fault path.
• For screen flows, the end user also sees an error message on screen; the detailed email still goes to the configured recipient.
• Record-triggered flows that fail generally roll back the triggering DML and display an error to the user who saved the record, while the error email goes to the configured recipient.
• Scheduled flows and platform-event-triggered flows run as the Automated Process user; errors appear in the error email and in Paused and Failed Flow Interviews.
• Error emails can also be routed to a custom notification or Slack via the Flow Error Notifications framework when using fault paths with custom logic.

How Debug Mode in Flow Builder Works

Click Debug in Flow Builder to open the debug panel. Important options include:

• Show details of what's executed and render flow in Lightning runtime – Displays the execution path and values.
• Run flow in rollback mode – Executes all logic but rolls back any DML, so test runs do not create or modify real records. This is available for autolaunched and screen flows.
• Run flow as another user – Available when the flow runs in User or System Context and the admin has the appropriate permission, allowing you to reproduce permission-related failures.
• For record-triggered flows, you choose a triggering record and whether to simulate a create or an update, and you can specify whether to skip the start condition requirements.
• For scheduled paths, you can debug a specific scheduled path.

The debug output highlights the path taken on the canvas and lists each element with the inputs it received and outputs it produced. When an element fails, the error message appears inline, making it the fastest way to pinpoint a problem. Debug mode runs the current version open in the builder, including unsaved changes, so you can iterate quickly before activating.

How Fault Paths Work

Any element that performs DML or calls an action exposes a fault connector. Common fault-handling patterns include:

• Displaying a user-friendly screen with the $Flow.FaultMessage global variable so users understand what went wrong.
• Sending a custom email using the Send Email action or an Email Alert, including $Flow.FaultMessage and record details.
• Creating a custom error log record for later review.
• Posting a Chatter message or custom notification to an admin group.

When a fault path exists, the flow does not send the standard error email and the interview is considered handled. This is a very common exam point: if the question asks why admins stopped receiving error emails after a developer added fault connectors, the answer is that the fault path suppresses the default notification.

Using Debug Logs for Flows

Set up a trace flag on a user in Setup under Debug Logs. In the debug level, the Workflow category controls flow logging. Setting it to Finer or Finest captures detailed FLOW_ELEMENT_BEGIN, FLOW_ELEMENT_END, FLOW_VALUE_ASSIGNMENT, and FLOW_BULK_ELEMENT events. Debug logs are especially useful when a flow is triggered indirectly by Apex, by another automation, or when the issue only occurs for a specific user in production where you cannot use Flow Builder debug mode on live data.

Paused and Failed Flow Interviews

Setup provides a Paused and Failed Flow Interviews page. Failed interviews are retained for review and can be deleted. Paused interviews (from Pause elements or Wait elements) can be resumed or deleted. Note that interviews can only be resumed by the user who paused them or by an admin with Manage Flow permission. This page is useful when a scheduled flow or asynchronous path fails and no user was present to see an on-screen error.

Common Flow Errors You Should Recognize

• The flow tried to update these records: null. You can look up ExceptionCode values in the Apex Developer Guide. – Usually a Get Records returned nothing and a later Update used the empty variable.
• UNABLE_TO_LOCK_ROW – Record locking contention, often in bulk or parallel operations.
• Too many SOQL queries: 101 – Governor limit hit, typically because a Get Records sits inside a loop.
• INSUFFICIENT_ACCESS_ON_CROSS_REFERENCE_ENTITY or FIELD_CUSTOM_VALIDATION_EXCEPTION – Permission or validation rule failures, often context-related (User vs. System Context).
• Flow version not active – The user ran a flow that was deactivated or never activated.
• Element limit exceeded (2,000 executed elements) – Loops processing too many records.

Exam Tips: Answering Questions on Debugging Flows and Flow Error Emails

1. Know the two error email recipient options cold. If a question describes error emails going to a former employee or an inconsistent person, the fix is to change Process Automation Settings to Apex Exception Email Recipients and populate that list.

2. Fault paths suppress default emails. If admins stop receiving error emails after fault connectors were added, that is expected behavior. The solution is to add an email action inside the fault path if notification is still needed.

3. $Flow.FaultMessage is the variable for the error text. Any question about showing users or admins the actual error message within a fault path points to this global variable.

4. Rollback mode is for safe testing. If the scenario stresses testing in production or avoiding test data creation, choose Debug with Run flow in rollback mode.

5. Run as another user diagnoses permission issues. When a flow works for the admin but fails for a specific profile, debug as that user or check the flow's run context (System Context Without Sharing vs. User Context).

6. Debug logs are the answer for indirect or production-only issues. If the flow is triggered by Apex, by another automation, or you need to see the exact sequence of automation on save, set a trace flag with Workflow at Finer or Finest.

7. Paused and Failed Flow Interviews covers asynchronous failures. Scheduled flows, scheduled paths, and Pause elements that fail without a user present are reviewed here.

8. Recognize governor limit patterns. Get, Create, or Update elements inside a Loop are the classic cause of SOQL or DML limit errors; the fix is to collect records in a collection variable and perform one DML after the loop.

9. Watch for distractors. Options like Workflow Rules, Process Builder, or writing Apex tests are rarely the best answer for a flow-debugging question when a declarative tool exists. Also, the error email setting is org-wide, so any option claiming per-flow email recipients via that setting is wrong.

10. Read for the keyword that signals the tool. See the path the flow took means Debug in Flow Builder; Who should receive errors means Process Automation Settings; Error occurred overnight with no user means Paused and Failed Flow Interviews or scheduled flow logs; Show users a friendly message means fault path plus $Flow.FaultMessage on a Screen element.

Summary

Debugging flows combines the interactive Debug feature in Flow Builder, fault connectors with $Flow.FaultMessage, debug logs with the Workflow category, and the Paused and Failed Flow Interviews page. Flow error emails are governed by the org-wide Send Process or Flow Error Email to setting, which should point to Apex Exception Email Recipients in production. Master how these pieces interact, especially the fact that handled faults do not generate the default email, and you will be well prepared for the scenario-based questions in this section of the Advanced Administrator exam.