As with anything, practice helps you improve – but if we’re talking honestly here, even the cleanest, best-thought-out flow can (and will) fail at some point. For some reason, maybe a user or a record isn’t there anymore, or maybe the user running it doesn’t have the right permissions, or your flow may be hitting governor limits.
Whatever the reason, Salesforce doesn’t exactly whisper a gentle warning or spoon-feed you an extremely detailed account of what went wrong and how to fix it. Most times, it just throws up one of those classic cryptic error messages (hello, “unhandled fault”?) and stops, after which the last admin who modified the flow gets an email with more info on what happened.
This is obviously not really a great experience for end users, right? Because these errors can cause confusion, it usually means more headaches for you when the users come knocking.
What Are Fault Paths For?
A fault path is like your alternate branch or backup plan, and it connects to parts of your flow that may fail, like data elements or actions. Normally, when your flow runs a “Get Records” or “Update Records”, it keeps going as long as everything works. But if something goes wrong, for example, the record can’t be found or the user doesn’t have access, your fault path’s role is to give the flow a chance to follow a different branch instead of failing.
I know, I know. Right now, especially if your flow is pretty simple, it’s tempting to skip error handling. It’s easy to feel confident that your flow “should” work. But oftentimes, real life in Salesforce is messy. Data isn’t always clean or perfect, users and their permissions change, and people can click buttons you didn’t expect them to. No matter how simple your flow may seem, it’s always good to consider setting up fault paths because, without them, when something breaks, the situation can cause users to stop trusting your flows.
What Can You Do with Fault Paths?
The main point to accept here is that these fault paths don’t prevent the error from happening. What you can do is manage how that error shows up. A clear error message keeps the user from feeling lost, while a log or notification gives you a trail to follow when it’s time to fix things. Over time, this is what builds trust. People are more likely to embrace your automations when they feel like the system has their back, even when something goes wrong.
What you do with it is up to you. The most common one is to firstly, show the user a friendly error message that actually makes sense instead of just “An unhandled fault occurred”.
This can be done by designing an error screen that shows the user an error message calling out the global variable {!$Flow.FaultMessage}. This is made to show a more detailed error, and despite being more technical and your user probably not having the tool to fix it, they at least get more context as to what actually went wrong.
You can see how I applied this in the flow we built together in this article. See how the message below shows the custom error along with more details as to why the error came to be (in this case, the flow hit a validation rule).
However, that’s not all you can do with fault paths! Check out the table below for an idea of what you can apply to your automations:
| Capability | What You Can Do | Reason to Use It |
|---|---|---|
| Show a user-friendly error message | In a Screen Flow, connect a fault path from a Data or Action element, like a Create Records or Update Records, for example, to a Screen element that displays the {!$Flow.FaultMessage} global variable within a custom message. It would also be nice to advise the user that the admin has been notified of the error. | The default “An unhandled fault has occurred” message is vague and may cause your users frustration. A clearer message helps them understand what went wrong, like the Flow may have hit a validation rule, etc. |
| Log the error internally | Use a fault path to Create Records in a custom object that you can name anything you want, like Flow Error Log, for example. This can be another place to use the {!$Flow.FaultMessage} global variable to display the error details, along with other things you might want to be able to view at a glance. | While you can also view paused and failed flow interviews in Setup > Paused and Failed Flow Interviews, or see errored flows in the Automation app, creating a custom object record for errors in your fault path preserves details of what failed alongside other information that your business would like to see, so admins can report on, review, trend issues, and debug later on. |
| Send alerts/notifications | From the fault path, use an Email action (or other notifications) to send error details to admins or support teams. | By default, the last admin who modified the flow receives a notification email when an error occurs. You can send notifications or emails to other users by adding the needed actions to your fault path. Especially for background flows or nightly automations where you may not notice failures immediately, this can be useful. |
| Call Subflows | Instead of replicating error-handling logic everywhere, you can attach the fault path to call a reusable subflow that handles error logic (like an autolaunched flow that does any of the capabilities above, for example). | This promotes consistency and saves maintenance effort and manual creation of the same actions over and over. For instance, a change in error handling in one subflow automatically applies everywhere that subflow is called. |
When it comes down to it, consider error management more than just a technical best practice, because it’s giving both you and your users a smoother, less frustrating experience!
Final Thoughts
Even if errors in flows are unavoidable, how you handle them will make all the difference.
A thoughtful fault path and a user-friendly error message will let your users know your automation can be trusted, the system isn’t broken, and your flow just hit a bump in the road!
Leave a Reply Cancel reply