Fault Paths and Error Handling in Flows

Why Fault Paths and Error Handling Matter

Flow Builder is now the primary declarative automation tool in Salesforce, and the Advanced Administrator exam expects you to build automation that is resilient, not just functional. In the real world, flows fail: a required field is missing, a validation rule blocks a save, a user lacks permission, a record is locked, an Apex action throws an exception, or an email cannot be sent. Without error handling, a single failure can stop a user mid-task with a cryptic system message, silently roll back a whole transaction, or flood an admin inbox with error emails.

Fault paths are how a flow 'catches' those failures and decides what to do next: show a friendly message, log the problem, notify an administrator, or gracefully exit. On the exam, this topic falls under the Process Automation domain, and questions usually present a scenario (a user sees an unhandled fault, an admin wants to be notified, a record-triggered flow should block a save with a custom message) and ask which design is best. Understanding fault connectors, default failure behavior, the $Flow.FaultMessage variable, the Custom Error element, and transaction/rollback behavior is essential.

What Is a Fault Path?

A fault path (also called a fault connector) is a special connector that leaves a flow element and is followed only when that element encounters an error at run time. Think of it as the declarative equivalent of a try/catch block in Apex: the 'try' is the element itself (for example, Create Records), and the 'catch' is everything connected to the fault path.

Key characteristics:
• A fault path is available only on elements that can fail at run time because they interact with the database or an external process.
• Each element can have one fault path, but the fault path can lead to any number of downstream elements (screens, record creation, email actions, assignments, subflows, and so on).
• If an element has a fault path, every error on that element follows the fault path and the normal outbound connector is skipped.
• If an element has no fault path, an error is considered unhandled and the flow fails.

Which Elements Support Fault Paths?

You can add a fault path to:
• Data elements: Create Records, Update Records, Delete Records, Get Records.
• Action elements: core actions (Send Email, Post to Chatter, Submit for Approval, Quick Actions), Email Alerts, Apex invocable actions, external service actions, and other Action-based elements.

You cannot add a fault path to logic or interaction elements such as Assignment, Decision, Loop, Collection Sort/Filter, Screen, Pause, or Subflow. If a subflow fails without handling the error internally, the error bubbles up and the parent flow fails as if the error occurred in the parent.

Exam nuance: A Get Records element does not fault when it finds no matching records; it simply returns null (or an empty collection). To handle a 'no records found' situation you use a Decision element that checks whether the variable is null, not a fault path. This is one of the most common distractors on the exam.

Default Behavior When a Flow Fails (No Fault Path)

Understanding what happens when there is no fault path is just as important as knowing how to add one.

• Screen flows: The user sees a generic error screen that reads something like 'An unhandled fault has occurred in this flow'. The current transaction is rolled back. An error email is sent to the configured recipient.
• Record-triggered flows (before-save and after-save): The flow runs in the same transaction as the record save. If the flow fails, the entire transaction is rolled back, including the original record change, and the user who saved the record sees an error. An error email is sent to the configured recipient.
• Schedule-triggered and platform event-triggered flows: There is no interactive user. The flow interview fails, changes in that transaction are rolled back, and the error email is sent to the configured recipient. For schedule-triggered flows, records are processed in batches, so a failure can affect the batch being processed.
• Autolaunched flows invoked from Apex, REST, or a process: The error is returned to the caller; the calling code or process determines what happens next.

The flow error email contains the flow name, version, the element where the error occurred, the error message, the running user, and the list of elements executed before the failure, which is extremely useful for debugging. Where this email goes is controlled in Setup → Process Automation Settings → 'Send Process or Flow Error Email to'. The options are the User Who Last Modified the Process or Flow (default) or Apex Exception Email Recipients, which is a list of users and external addresses you maintain under Setup → Apex Exception Email. If the exam asks how to ensure a shared team or a distribution list receives flow failures, the answer is to use Apex Exception Email Recipients.

How Fault Paths Work: Building and Using Them

1. Adding a fault path. In Auto-Layout, click the plus icon below the element and choose Add Fault Path, or open the element's menu and select Add Fault Path. In Free-Form, drag a second connector from the element; Flow Builder automatically labels it as the Fault connector (shown with a red/fault label). The element now has two outbound routes: the normal path and the fault path.

2. Using $Flow.FaultMessage. When an element fails, Salesforce populates the global variable {!$Flow.FaultMessage} with the system error text (for example, a FIELD_CUSTOM_VALIDATION_EXCEPTION message from a validation rule, or INSUFFICIENT_ACCESS_OR_READONLY). This variable is meaningful only within the fault path. Typical uses include writing it to a text field on an error log record, inserting it into an email body sent to the admin, or displaying it on a screen in an internal admin tool. Related global variables often used alongside it are {!$Flow.CurrentDateTime}, {!$Flow.InterviewGuid}, {!$Flow.CurrentRecord}, and {!$User.Id} for context.

3. Common fault path patterns.
• Friendly error screen: In a screen flow, route the fault path to a Screen element with a Display Text component telling the user what happened in plain language and what to do next. Best practice is to avoid showing raw system messages to end users and customers; show a friendly message and log the technical detail separately.
• Error logging: Route the fault path to a Create Records element that inserts a custom Flow Error Log object (or a Case) capturing $Flow.FaultMessage, the flow name, the running user, the record Id, and a timestamp. This builds a searchable, reportable history of failures.
• Admin notification: Route the fault path to a Send Email action or an Email Alert that includes $Flow.FaultMessage, so the admin learns of the problem immediately even though the user was shown a friendly message.
• Graceful continuation: Sometimes the failed step is non-critical (for example, posting to Chatter). The fault path can simply reconnect to the next element so the flow continues, while optionally logging the issue.
• Reusable error-handling subflow: Build an autolaunched subflow that accepts the fault message, flow name, and record Id as inputs and performs the logging and notification. Call it from every fault path to keep flows consistent and maintainable.

4. Fault paths and transactions. A fault path does not undo what already succeeded in the current transaction. If a flow created a record, then a later Update Records element failed and went down a fault path, the earlier create still exists unless the whole transaction is rolled back. In screen flows, use the Roll Back Records element inside a fault path to roll back all record changes made in the current transaction, then show a message. Note that in screen flows a transaction ends when the flow reaches a Screen, Pause, or Local Action element, so Roll Back Records only affects changes since the last transaction boundary.

5. What fault paths cannot catch. Fault paths do not catch governor limit exceptions (such as too many SOQL queries or DML statements) or errors from elements that do not support fault connectors. A fault path also does not catch errors in a different element; each element must have its own fault path. If an invocable Apex method catches an exception internally and does not rethrow it, the flow sees success and the fault path is not taken.

The Custom Error Element (Record-Triggered Flows)

Introduced in Spring '24, the Custom Error element lets a record-triggered flow (before-save or after-save) stop the record from being saved and show a custom error message to the user, similar to a validation rule but with the full logic power of Flow. You can display the message either at the top of the record page/window or inline on a specific field. When a Custom Error element executes, the whole transaction is rolled back, including the triggering record change and any changes made earlier in the flow.

Typical uses: enforce complex cross-object rules that a validation rule cannot express (for example, block closing an Opportunity if related Quotes are still in Draft), or place a Custom Error at the end of a fault path so that a failure in a related record update rolls back everything and tells the user why in plain language. The Custom Error element is only available in record-triggered flows, not screen, scheduled, or autolaunched flows.

Debugging and Monitoring Errors

• Debug in Flow Builder lets you run the flow with sample inputs and see each element's result, including errors, without committing changes (unless you choose to). With 'Let admins debug flows as other users' enabled in Process Automation Settings, you can debug as a specific user to reproduce permission-related faults.
• Flow error emails show the failing element and the sequence of executed elements.
• Paused and Failed Flow Interviews (Setup → Flows → Paused and Failed Flow Interviews) shows interviews that failed or are waiting; you can resume or delete them.
• Error log reports on a custom object populated from fault paths give long-term visibility that emails do not.
• Errors do not deactivate a flow; the active version stays active and will fail again for the same inputs until fixed.

Best Practices Summarized

• Add a fault path to every Create, Update, Delete, and Action element in production flows.
• Never expose raw fault messages to external users; show a friendly message and log details for admins.
• Centralize error handling in a reusable subflow.
• Route failure notifications to Apex Exception Email Recipients rather than a single admin who may leave the company.
• Use Decision elements, not fault paths, to handle 'no records found'.
• Use Custom Error in record-triggered flows when the user should be blocked with a meaningful message.
• Use Roll Back Records in screen flows when a partial success would leave bad data.
• Check for null before using a record variable's fields to prevent avoidable faults.

Exam Tips: Answering Questions on Fault Paths and Error Handling in Flows

Tip 1: Match the keyword to the feature.
• 'Users see An unhandled fault has occurred' → the element that failed has no fault path; add one and route it to a Screen with a friendly message.
• 'Admin wants to be notified when a flow fails' or 'include the error details' → fault path to a Send Email action (or Email Alert) using {!$Flow.FaultMessage}, or configure Apex Exception Email Recipients in Process Automation Settings.
• 'Track or report on errors over time' → fault path that creates a custom error log record (or Case) storing $Flow.FaultMessage.
• 'Prevent the record from being saved and show the user a specific message in a record-triggered flow' → Custom Error element.
• 'Undo records already created earlier in a screen flow when a later step fails' → Roll Back Records element in the fault path.
• 'Flow should continue even if the Chatter post or email fails' → fault path that reconnects to the next element.

Tip 2: Know which elements have fault connectors. If an answer suggests adding a fault path to a Decision, Assignment, Loop, Screen, or Subflow element, it is wrong. Only data elements and action elements support fault paths.

Tip 3: Remember Get Records does not fault on no results. Questions describing 'the flow should handle the case where no matching Contact exists' are testing the Decision element with an 'Is Null' check, not a fault path. Conversely, a fault path on Get Records is for genuine errors, such as a field-level security or query failure.

Tip 4: Understand default failure behavior. Know that an unhandled fault rolls back the transaction, that record-triggered flow failures block the user's save and show an error, and that the error email goes by default to the user who last modified the flow. If the question mentions a former employee receiving the emails or a team needing visibility, the fix is Apex Exception Email Recipients.

Tip 5: $Flow.FaultMessage is only available in the fault path. If an answer uses it on the normal path or in a Decision before an error occurs, eliminate it. Also remember it contains the system message, which is why best practice is to log it rather than show it to customers.

Tip 6: Fault paths do not catch governor limits. If a scenario describes 'Too many SOQL queries' or 'Too many DML statements', the solution is to redesign the flow (move DML outside the loop, use collections) rather than add a fault path.

Tip 7: Favor declarative, scalable, maintainable answers. When two answers both work, the exam prefers the one that is reusable (an error-handling subflow), does not require code (Flow over Apex), and provides a good user experience (friendly screen plus admin notification over a raw error). Be wary of answers that recommend Apex triggers or Process Builder when a Flow feature solves the problem.

Tip 8: Read the flow type carefully. Screen flow scenarios allow Screen elements and Roll Back Records in the fault path. Record-triggered flows allow Custom Error but not Screens. Schedule-triggered and platform event flows have no interactive user, so error handling should log and notify rather than display.

Sample Question Walkthroughs

Scenario 1: A screen flow used by support agents creates a Case and then updates the related Account. Sometimes the Account update fails due to a validation rule, and agents see a system error and lose their work. What should the administrator do?
Approach: Add a fault path to the Update Records element. In the fault path, use a Roll Back Records element to remove the Case created earlier, then a Screen with a friendly message, and optionally a Create Records element to log $Flow.FaultMessage. Answers that mention only 'tell agents to retry' or 'add a fault path to the Decision element' are wrong.

Scenario 2: A record-triggered flow on Opportunity must stop users from marking an Opportunity Closed Won if any related Quote is still in Draft, and show them why.
Approach: Use a Get Records to find Draft Quotes, a Decision to check whether any were found, and a Custom Error element to block the save with a clear message. A validation rule cannot see child records, so Custom Error is the correct declarative choice.

Scenario 3: The admin who built most flows has left the company, and nobody is receiving flow failure notifications.
Approach: Change 'Send Process or Flow Error Email to' in Process Automation Settings to Apex Exception Email Recipients, and add the current admin team (or a distribution list) there. Rebuilding flows or reassigning ownership one by one is not the best answer.

Scenario 4: A flow calls an Apex invocable action that occasionally throws an exception. The admin wants the flow to log the exception text and continue.
Approach: Add a fault path to the Apex action element, route it to a Create Records element that stores {!$Flow.FaultMessage} in a log object, then connect back to the next element on the main path.

Final Takeaway

Fault paths turn fragile automation into dependable automation. For the exam, remember the core facts: fault connectors exist on data and action elements only; an unhandled fault rolls back the transaction and fails the flow; $Flow.FaultMessage carries the error text inside the fault path; Custom Error blocks saves with a tailored message in record-triggered flows; Roll Back Records cleans up partial work in screen flows; error emails go to the last modifier or Apex Exception Email Recipients; and 'no records found' is a Decision, not a fault. Pair those facts with the habit of choosing user-friendly, reusable, declarative designs, and you will handle every error-handling question with confidence.