A broken flow can leave a qualified lead unassigned, create duplicate tasks, or send a Closed Won deal to onboarding without the details they need. Salesforce Flow error handling gives revenue teams a controlled response through a fault path, instead of a vague error message, an unhandled fault, and a cleanup project.
The strongest exception handling setup protects the user experience, preserves trustworthy CRM data, and alerts the people who can fix the issue. Start by treating exceptions as normal operating conditions, especially at revenue handoff points.
Key takeaways for revenue operations
- Add a fault path after every risky data or action element in a revenue-critical Salesforce flow.
- Give users a clear next step, while keeping technical fault details for administrators and support staff.
- A fault path doesn’t automatically reverse the transaction, so choose rollback behavior deliberately.
- Treat exception handling as an operational practice by logging failures for reporting and reviewing patterns with SLA and routing metrics.
- Test incomplete records, duplicate matches, permission restrictions, and repeat updates before activating the flow.
Build Salesforce Flow error handling around real revenue risk
Revenue automation often crosses ownership boundaries. A Lead might move from a queue to an SDR, an Opportunity may create an onboarding task, or a conversion may create related Account and Contact records. Each step can fail after earlier changes have already affected revenue operations.
What an unhandled fault means
An unhandled fault occurs when a flow element encounters an error and has no configured route to follow. A fault path provides an alternate route for handling that failure. Common failure points include Create Records, Update Records, Delete Records, Get Records, and an Apex action.
Common triggers include a validation rule, a missing required field, a duplicate match, an invalid picklist value, or access restrictions. A flow can also collide with assignment rules, Apex triggers, or other automation that updates the same record.
The default Salesforce error message doesn’t tell a sales rep what to fix. Worse, it can leave an admin with an email alert but no useful operating record of how the failure affected lead routing or a customer handoff.
Treat exception paths as part of the workflow
A reliable handoff flow has a happy path and an exception path. Before building, document the trigger object, required fields, owner change, task, alert, SLA timestamp, and fallback owner or queue.
For example, a flow triggered when Lead Status changes to “Sales Ready” should check qualification fields before assigning an SDR. If a country, segment, or product interest is blank, route the record to a fallback owner or queue for review, with a measurable response time.
Good exception handling treats missing data and routing conflicts as expected operating conditions. They need an owner, a queue, and a measurable response time.
Configure fault paths in Flow Builder
In Flow Builder, a fault connector is a secondary route from an element that runs when that element fails. Salesforce supports fault connectors for data and action elements, including Apex actions, Create Records, and Update Records steps. The official fault path guidance from Trailhead shows how to connect that fault path to an alternate response.
Add the fault connector after risky actions
In Flow Builder, open the element that writes data or calls an action. Select the fault connector, then connect it to the response Salesforce should use.
For a revenue workflow, use this exception handling sequence:
- Capture context that can help support investigate, such as the source record ID, flow name, failed element, and business process.
- Route the branch to an error message, an email notification, a Case record, platform events, or a custom log record.
- End the path after the response, unless the flow has a safe recovery action that doesn’t repeat the failed work.
Store useful values before the risky element runs. If a failed update prevents a later assignment, the error-handling branch should still have the source Lead or Opportunity ID.
Match the response to the flow type
A screen flow can display a Screen element after an error. This works well when a rep can correct the information and try again.
A record-triggered flow runs in the background, so it can’t display an interactive screen. It needs another response, such as a custom error to block the save, an email notification to revenue operations, a Case for an exception queue, or a durable log record.
Flow behavior and available elements can vary by flow type, release, edition, and org configuration. Test the exact design in a sandbox with the same profiles, validation rules, and integrations used in production.
Give users a useful message without exposing diagnostics
Users need enough information to correct the record or contact support. Administrators need error details that reveal the failing field, validation rule, or downstream action. Good exception handling keeps those needs separate.
Use FaultMessage for troubleshooting context
Salesforce provides the $Flow.FaultMessage global variable, which contains the system fault message administrators can use to investigate runtime errors. Salesforce documents it in the $Flow global variables reference.
In a screen flow, add a Display Text component on the fault screen and insert Running Flow Interview > FaultMessage. Use the fault connector to route the diagnostic branch to this screen. Keep that fault path separate from the screen shown to sales users.
This setup is useful during administrator testing and for internal tools used by trained operations staff. However, don’t automatically expose the raw system error message to every sales user. It can be technical, confusing, or include details that don’t help the user resolve the problem.
Write a business-facing custom error
Use a plain-language error message that describes the action the rep should take. A message such as “Add the customer segment before submitting this lead” is better than a database error.
For record-triggered flows that must block an invalid save, use a custom error tied to the business rule. Salesforce also provides fault-connector examples that cover requesting corrections and bypassing an error.
Keep the technical fault message in an admin notification or error log. That separation shortens support conversations and prevents reps from guessing at a fix.
Choose transaction behavior before you add a fault path
Fault handling changes what happens after an error. Transaction behavior matters when a flow assigns ownership, creates follow-up tasks, stamps SLA dates, or creates related records.
A standard branch can allow the trigger to succeed
A fault response doesn’t automatically roll back the transaction. Salesforce’s rollback and custom error lesson explains that when a flow follows that response, Salesforce can complete the change that triggered the flow.
For example, an Opportunity may move to Closed Won even if the flow fails to create an onboarding task. That may be acceptable if the response creates a support Case and alerts the onboarding manager. The right transaction behavior depends on whether the handoff task must exist before the stage change is valid.
Use Roll Back Records in eligible screen flow designs
Salesforce’s Roll Back Records element cancels pending record changes from the current transaction. Salesforce documents its use in a screen flow response to cancel pending changes when an element fails. Review the current Roll Back Records release guidance before adopting it, since eligibility can vary by flow type and configuration.
Rollback can’t undo actions outside that transaction, such as an external integration that already accepted a request. Downstream publication through platform events or external processing should not be assumed to roll back either. Rollback also doesn’t replace an investigation workflow for records affected before or after the failed flow.
Block unsafe record saves with custom error
For a record-triggered flow, a custom error is often the right response when bad data would cause downstream damage. Use it when a sales handoff lacks required information, an owner can’t be resolved, or a reopened Opportunity would create duplicate onboarding work.
Fail fast when the record is incomplete. A task on a half-finished record may look like successful automation, yet it creates missed SLAs and manual cleanup. That exception handling approach protects the process when downstream work depends on valid data.
Design logging and alerts that people will use
Email alerts are useful, but an inbox isn’t an error-management system. Revenue teams need enough context to identify patterns, prioritize revenue risk, and confirm that an exception was resolved.
Send actionable administrator notifications
Salesforce recommends configuring a fault connector so administrators receive an email when a flow fails. Follow its guidance to configure fault-path email alerts.
Include the flow name, source record link or ID, failed element, error message, error details, affected owner, and business impact. Map FaultMessage into the notification or log so a system administrator can understand the failure quickly. A notification that says “lead routing flow failed” isn’t enough to act.
For high-priority processes, use Create Records on the response route to create a Case and assign it to an operations queue. Include the source record, flow, failed element, owner, business impact, and case creation status. Use a dedicated record type or clear subject pattern so routing failures don’t disappear among ordinary support requests.
Choose platform events and custom logs carefully
FlowExecutionErrorEvent is a standard platform event for errors related to screen-flow executions. It is available in API version 47.0 and later, according to Salesforce’s FlowExecutionErrorEvent field reference.
The documented scope of FlowExecutionErrorEvent matters. Platform events may support an event-driven monitoring design, but don’t treat this event as a universal logger for a record-triggered flow or other background automation.
A custom object can be a better option for reportable error logging across revenue processes. An org may choose platform events when an event-driven monitoring design fits its operational needs. Typical fields include the source record, flow API name, error category, fault message, owner or queue, timestamp, status, and resolution notes. Keep the custom object narrow, because custom logging adds storage, DML activity, permissions, and retention work.
Where Apex belongs in a fault-handling design
Flow can call invocable Apex when the work needs code, such as complex matching, a reusable calculation, or an integration pattern that Flow can’t support cleanly. The Apex action can expose a failure to Flow through a fault connector. For asynchronous side effects, platform events require their own error and retry considerations.
Use try and catch inside Apex for exception handling when code needs to handle an expected exception, add context, clean up controlled work, or decide whether to rethrow an error. If Apex catches an exception and returns a normal result, Flow won’t enter its fault path. If Apex rethrows an exception, Flow can handle the failed action.
Keep responsibilities clear. Apex should manage code-level behavior. Flow should decide the business response, such as whether to block a handoff, notify RevOps, open a Case, or route a record to an exception queue.
For invocable methods, design for bulk processing and avoid hidden side effects. A catch block that silently ignores a failed record can be worse than a visible fault because it creates a false sense of completion.
Test Salesforce Flow error handling like a revenue workflow
Activation proves only that Salesforce accepted the flow definition. It doesn’t prove that leads reach the right owner or that a failure creates a usable recovery path.
Test the normal path and deliberate failures
Use a sandbox checklist that covers a standard Lead, an incomplete Lead missing a required field, a validation rule rejection, a duplicate match, a routing conflict, restricted access, invalid picklist values, and a record edited by a non-admin profile. Also test repeated updates and reopened Opportunities when the workflow creates tasks or customer handoffs.
Verify the source record, owner history, related tasks, notification, log entry, and final transaction outcome. Confirm that each risky element reaches its intended fault path. Check whether repeat updates create duplicate alerts or tasks.
A debug panel can help isolate a sandbox issue, but it doesn’t replace testing with realistic permissions and active automation.
Review exceptions as operating data
Build reports that answer practical questions: How many records entered the workflow? What percentage met the SLA? Which owners or queues receive the most exceptions? How often do duplicates block routing? Which tasks remain open after an owner change?
Confirm that error logging creates durable, reportable records in the selected custom object or other approved destination. If the org uses platform events within its documented scope, verify that FlowExecutionErrorEvent records the expected failures and supports the intended alert or recovery process.
Audit every active flow, assignment rule, Apex trigger, and integration that touches the same object. Overlapping automation often causes more damage than a single flawed decision element.
Assign a business owner for each revenue-critical flow and a technical owner for its maintenance. Review exception volume weekly, then run a deeper audit after changes to fields, validation rules, routing logic, integrations, or lifecycle definitions.
FAQ
How can administrators prevent an unhandled fault message?
Add a fault path to each risky data or action element before activation. Route it to a screen message, Custom Error, email notification, Case, or error log based on the flow type and business risk.
Can a fault path automatically create a Case for IT or RevOps?
Yes. Add a Create Records element to the path and create a Case assigned to an exception queue. Include the source record, flow name, fault message, and failure category. This supports case creation without requiring the assignee to reconstruct the event.
Does a fault path roll back the transaction?
No. That routing option alone doesn’t cancel pending changes. Use the appropriate rollback or Custom Error design when the record change itself must not succeed.
Can platform events replace in-flow error handling?
No. FlowExecutionErrorEvent can support monitoring for certain flow execution failures, but coverage depends on supported flow types and org configuration. It doesn’t control rollback or replace user-facing error handling.
Make exceptions visible before they become revenue gaps
An exception strategy is more than a technical safeguard. It protects response time, record quality, ownership clarity, and the trust teams place in Salesforce automation.
Build Salesforce Flow error handling around clear business rules and actionable error data. Decide your transaction behavior before an exception occurs: block the save, preserve the change, or create a follow-up operating record. The best workflow handles failed actions without hiding them from the people responsible for the next step.
