If you’ve built Flows for any length of time, you’ve probably had this morning. You open your inbox and there it is: an email with the subject line “Error Occurred During Flow” and a wall of text underneath it. Meanwhile, a sales rep is messaging you because they clicked Save and got a scary red message that said “An unhandled fault has occurred in this flow.”
I’ve been there more times than I’d like to admit. The flow worked fine in the sandbox. It worked fine when I tested it. Then a real user with real data and a slightly different permission set touched it, and it fell over.
The fix, most of the time, isn’t a smarter flow. It’s a fault path in Salesforce Flow. So let’s talk about what fault paths are, how to use them properly, and a couple of traps I wish someone had warned me about earlier.
What Is a Fault Path in Salesforce Flow?
A fault path is the route your flow takes when an element fails. That’s it. Normally, an element has one connector that says, “When you’re done, go here.” A fault path adds a second one that says, “If something goes wrong, go here instead.”
Normal Path vs. Fault Path
When Update Records works, the flow carries on as normal. When it fails, the flow drops down to the red branch instead of crashing.
If you’ve written any code, it’s basically a try/catch. Without it, the flow just stops dead, and Salesforce shows the user a generic error. With it, you get to decide what happens next: log the problem, tell the user something useful, notify an admin, or quietly carry on.
The things that cause faults are usually boring. A validation rule blocks the save. A required field is empty. The running user can’t edit that record. Someone else has the record locked. An Apex action throws an exception. None of these are exotic, which is exactly why they catch you out.
Where Can You Add a Fault Path in Salesforce Flow?
Not every element gets a fault path. Assignments and Decisions don’t, because they can’t really fail in a way the platform cares about. The ones that do are the elements that talk to the database or to something outside the flow:
- Create Records, Update Records, Delete Records, and Get Records
- Action elements, including Apex actions, Send Email, and other invocable actions
Adding one is easy. In Auto-Layout, click the element and choose Add Fault Path. A new branch appears with a red “Fault” label, and you build on it like any other path. In Free-Form, drag a second connector out of the element, and Flow Builder will mark it as the fault connector automatically.
Adding a Fault Path: 3 Steps
That’s the whole setup. The real work is deciding what goes on the branch.
My rule of thumb is simple: if an element touches data, it gets a fault path. Every time. Even the ones I’m “sure” won’t fail.
What Should You Add to a Salesforce Flow Fault Path?
A fault path that goes nowhere is better than nothing, but only just. It swallows the error, and now nobody knows anything broke. That’s arguably worse. Here’s what I put on mine, depending on the flow.
1. Capture the Error Message Using $Flow.FaultMessage
Salesforce gives you a system variable called $Flow.FaultMessage. It holds the actual error text, like the validation rule message or the “insufficient access” error. Whatever else you do, capture this. It’s the single most useful thing when you’re debugging later.
2. Display a User-Friendly Error Message in Screen Flows
Add a Screen element on the fault path with something human: “We couldn’t save this opportunity. Please check the close date and try again, or contact your admin.”
You can include $Flow.FaultMessage if your users can handle it, but I usually keep the raw text for the log and give users the friendly version.
3. Log Salesforce Flow Errors
Log the error somewhere you’ll actually look. A custom object for flow errors works well (more on that below). Emails to admins are fine for low-volume orgs, but they get ignored fast once there are dozens a day.
4. Decide Whether to Stop or Continue the Flow
Sometimes a failure is fatal, and the flow should end. Other times, say a nice-to-have task creation fails, you can log it and connect the fault path back into the main flow so the important stuff still happens.
Salesforce Flow Fault Paths: Common Mistakes and Gotchas
This is the part that bit me hardest, so I’ll be blunt about it.
1. A Fault Path Doesn’t Undo Previous Changes
Say your flow creates an Account, then fails while creating the Contact. If the fault path catches that error, the Account still gets saved. You’ve “handled” the error and left a half-finished job behind.
In screen flows, you can drop a Roll Back Records element on the fault path to undo the earlier changes. Use it whenever partial data would cause problems.
2. Handling Errors in Record-Triggered Flows Can Hide Them
Without a fault path, an error rolls back the whole save, and the user sees it. With one, the save goes through, and the user may never know. That’s sometimes what you want and sometimes really not. Think about which one you need before you add the path.
3. Get Records Returning No Results Is Not a Fault
This trips up a lot of people. If your Get Records returns no rows, the flow doesn’t fault. The variable is just empty. Then a later element tries to use it, and that one fails.
Put a Decision after your Get Records to check for null, and don’t rely on the fault path for this.
4. Faults Inside Loops Can Create Excessive Logs
If an Update inside a loop fails for every item, you’ll log the same error 200 times. Better still, collect your records in the loop and do one Update after it. That’s good practice anyway.
How to Build a Reusable Salesforce Flow Error Logging Subflow
After building the same “log the error” steps into flow after flow, I finally did the sensible thing and made one subflow for it. Every fault path now just calls that.
Here’s the setup:
- Create a custom object. Create something like Flow Error Log, with fields for Flow Name, Error Message (long text), Record Id, Running User, and a timestamp.
- Build an autolaunched flow. Call it something like Log Flow Error. Give it input variables for each of those fields.
- Create the error log record. Inside the subflow, a single Create Records element saves the log.
- Connect the subflow to your fault paths. On every fault path in your other flows, add a Subflow element that calls Log Flow Error and passes in $Flow.FaultMessage, the flow’s name, and the record Id.
Salesforce Flow Error-Logging Subflow Pattern
Every flow’s fault path points at the same subflow, so all your errors land in one place.
Now you have one list view or report that shows every flow error in the org. Sort by date, group by flow name, and you’ll spot problems before users start messaging you.
One honest caveat. If the whole transaction gets rolled back, your log record can get rolled back with it. If you need logs that survive no matter what, publish a platform event set to publish immediately, and have a separate flow subscribe to it and create the log. It’s a bit more setup, but it’s the reliable version.
Conclusion
Fault paths aren’t glamorous. Nobody demos them in a sprint review, and no stakeholder ever says “great error handling!” But they’re the difference between a flow that quietly deals with a bad day and one that dumps a cryptic error on a user and an email in your inbox.
If you take one thing from this post, make it this: every element that touches data gets a fault path, and every fault path does something useful with $Flow.FaultMessage. Build the logging subflow once, and you’ll thank yourself every time something breaks.
Go open your busiest flow and count the red Fault branches. If the answer is zero, you know what to do this week.
Have a fault path trick of your own? I’d love to hear it in the comments.
About Us
Greytrix – a globally recognized and one of the oldest Sage Development Partner and a Salesforce Product development partner offers a wide variety of integration products and services to the end users as well as to the Partners and Sage PSG across the globe. We offer Consultation, Configuration, Training and support services in out-of-the-box functionality as well as customizations to incorporate custom business rules and functionalities that require apex code incorporation into the Salesforce platform.
Greytrix has some unique solutions for Cloud CRM such as Salesforce Sage integration for Sage X3, Sage 100 and Sage 300 (Sage Accpac). We also offer best-in-class Cloud CRM Salesforce customization and development services along with services such as Salesforce Data Migration, Integrated App development, Custom App development and Technical Support business partners and end users. Salesforce Cloud CRM integration offered by Greytrix works with Lightning web components and supports standard opportunity workflow. Greytrix GUMU™ integration for Sage ERP – Salesforce is a 5-star rated app listed on Salesforce AppExchange.
The GUMU™ Cloud framework by Greytrix forms the backbone of cloud integrations that are managed in real-time for processing and execution of application programs at the click of a button.
For more information on our Salesforce products and services, contact us at salesforce@greytrix.com. We will be glad to assist you.