How to Solve Salesforce Flow Errors
Salesforce Flow errors are inevitable when you are building these automated processes. Did you know that you can create a nice, clean user experience when an error occurs? Providing users with a clear and concise error message lets them know what’s gone wrong.
This is known as Salesforce Flow “fault handling”, the best practices for managing, debugging, and avoiding errors in your Salesforce Flows.
I’ve said it before, and I’ll say it again – Salesforce Flow is the greatest tool in a functional Admin’s toolbelt. You can easily implement your custom business logic into the system and make things happen automatically without any input from your users. You can also create custom user Interfaces to prompt for information using Screen Flows, and embed them into a Lightning Page or allow them to be launched from Buttons. However, as with any technology, there is room for errors and faults…
What is an Unhandled Fault?
An “unhandled fault” is thrown when something happens inside your Flow that goes against what Salesforce is expecting. This could be something as simple as pushing a record without a required field being populated, or something more sinister like a governor limit being hit (which means too many SOQL queries).
How to Create Flow Error Messages
As a user, when you’re simply going about your day and trying to get work done, there’s nothing more frustrating than being met with an error that doesn’t have a human-friendly explanation. Users are bound to get annoyed and may eventually start looking for workarounds outside the system. The error below is an example of the default error that a user may encounter while using Salesforce:
This is the standard behavior when a Flow fails, as the official Salesforce Documentation states.
As much as you should design our Flows to be less prone to errors (more on that later), errors are bound to occur sometimes – especially on more complex Flows. You want your users to know what specifically caused the error, especially if it’s something that can easily be fixed so they can finish the task at hand. There are a number of ways that you can do this.
Using Decisions to Avoid Flow Errors
To avoid hitting a ‘fault’ altogether, you can use a Decision to check specific criteria before proceeding and loop the user back around if you need to clean up or gather additional information.
You can create custom Screens to explain an error. For example, using the flow example from a previous article, if you want to let your users know that the Account they’re referencing has no Contacts, you’d need to create a Screen after the Get Contacts explaining this, and put a Decision element that decides the whether or not the countContacts variable (the number of records in the Collection) is greater than or equal to 1.
If the Account has less than 1 Contact, you may want to let the user go back and select a different Account, or close out the Flow altogether – either way, you’ve successfully avoided hitting an error!
Creating a Custom Error Message for Users and Admins
According to Salesforce best practice in this help article, you should always configure the Fault Connectors to inform you when a Flow fails. This helps you to spot any consistent errors before they become a headache for your users, or at the very least gives you easy access to some key information when a Flow does inevitably fail and a user wants to know what went wrong.
The example below sits at the bottom of a Flow that creates a new Lead record.
In our example above, the problem is that the Flow was pushed to Production before it was properly tested, and doesn’t collect the required field “Company” on the Lead. Without a custom error message, your users will simply see the default error which won’t tell them anything except “IT’S NOT WORKING!”
So just how do you create a Fault line? Good question! On Data elements (Create, Update, Get, and Delete) you’ll notice that even after dragging your node to the next element, the node is still visible. This is because there is more than one path that can be created – the standard path, and the fault path. Simply drag the node to the Screen you want displayed if an error occurs, and the red Fault path will be created.
With a custom Error Screen, your users will be able to see a little more information and should be able to identify that the issue is related to the “Company” field, which is missing. You’ll also get a copy of the same error in your email (with additional information such as their input values, the time the Flow was run, and who ran it).
Flow Errors Caused by Inactive Users
Errors may sometimes occur if a user is inactive. This happens most commonly when someone leaves the organization. If a user assigned to the Flow is no longer active, when trying to resume a Flow interview that has been paused, you will cause an error.
The easiest solution to this issue is to freeze your users and ensure all Flow interviews assigned to that particular user are complete before fully deactivating them.
Change Who Receives Flow Error Emails
The Process Automation Settings in Setup shows you who should be receiving the Flow error emails. You can select whether it will be the ‘User Who Last Modified the Process or Flow’, or ‘Apex Exception Email Recipients’ (this is a list of users specified on the Apex Exception Email page).
Is There a Way to Ignore Salesforce Flow Errors?
You can also ignore a Fault altogether by dragging the Fault line to the same place as the success line. Generally, this is not recommended, and should only be done in certain niche circumstances, such as ensuring a Contact is part of a specific Campaign.
An error will be thrown when you try to add a Contact to a Campaign, but your user would be allowed to continue with the rest of the Flow.
Use Salesforce Cases to Manage Flow Errors
If your IT Helpdesk runs inside of Salesforce using something like Cases, not only could you send an email with the Flow error details, but you could also create a Case to ensure there is a follow-up. Doing something like this will help build trust between your users and Salesforce, as they’ll begin to learn that the platform is constantly evolving and improving, and they’re not going to see the same issue multiple times over.
Accessing List of Failed Flow Interviews in Setup
To see a list of All Failed Flow Interviews in Setup, simply search for ‘Paused and Failed Flow Interviews’ in Setup’s Quick Find bar, and switch to the All Failed Flow Interviews List View. Simple!
I’ve said it before, and I’ll repeat it until the day I retire – Flows are powerful. They allow you, as an Admin, to configure your system with custom automated logic and easy-to-use screens for your users, but there’s no doubt they’ll fail from time to time. The best solution is to anticipate this and build correct Fault Handling into your Flow design, so you can manage it better when they do occur.
Annoying that you can’t add an error screen to a Record Triggered Flow
How would that even work?
Yes! I’m trying to figure this same process out now.
Today I discovered while developing a fault path into a Record Trigger Flow there is an option on the fault for a sub flow action. I’ve created a screen flow in hopes of using it as a sub flow but have not been able to retrieve/surface the screen flow with the record trigger flow error. Disappointing.
By the way, great article Tim, at least 3 takeaways, things I did not know. Keep them coming.
I have a couple of schedule-triggered flows for daily reminder emails at 8 am for my outside sales reps. They send email alerts when they have a follow-up object that is due the following day, and then another flow for when it goes overdue by 3 and 7 days. These criteria are count fields for “days before due date” and “days past due”. So obviously, there are days where there are not any follow-ups due the next day or overdue by exactly 3 or 7 days, and on those days I get an email for “Error Occurred During Flow “Follow-Up Overdue Email Alerts”: Probably Limit Exceeded or 0 recipients” How can I prevent this error email, since it’s not really a “failed” flow, there just weren’t any that needed to be sent that day. I had to setup the flows up as schedule-triggered instead of record-triggered to time the reminder emails for my reps, because the Due Date field is a date only field and it is part of an installed package that I cannot manage, so I couldn’t change it to a date/time field, and my reps were complaining about getting the reminder emails at 12:01 am.
We have a Flow, used on our website for customers. Very infrequently (about 1%) I get the “FlowApplication” email that tells me there was an error, and the error indicates required images version IDs did not exist. So I know the customer got the frustrating “unhandled fault” error screen, and they would have to start the process (Flow) from scratch.
However, images ARE required, so why this sometimes happens I do not know or understand.
My question is this:
If I use the “Fault” path with a Screen element, and a Screen element with a generic “Something went wrong, please hit the ‘Back’ button, make sure your images are listed and try again.”.
– Give them a “Back” button, and they simply make sure their images are listed and try again?
Would that solve this rare, but frustrating problem?