This week I would like to go over a few ideas about error message design in screen flows.
You probably already know that you can build fault paths coming out of various elements in flow. These paths will allow you to take a different route when the fault occurs. The inconvenient truth about these fault paths is that the flow will still generate an error email. If you are an admin with tens of these flows active or a consultant with hundreds of them running, you would not want to receive emails. So, going down the fault path is like avoiding an accident but with a scratch. Therefore you should build fault paths but preferably avoid using them.
How can you do that?
The field validation inside your screen element is your first tool to avoid errors. Remember; your screen flow is unaware of the validations you built on the object. This means that you need to create the same validations inside your flow, so that you don’t face any errors when your flow creates or updates an object record.
Your next step is to use decision elements to predict and handle all possible outcomes. Then, connect your outcomes to human-readable error messages on screen elements that allow the user to take the necessary actions.
Let me give you an example: You have a screen flow guiding the user with creating an order. And the user can select how the ordering party will pay. Among the payment choices, there is the credit card option. However, you don’t have the credit card information for some clients entered into the system. In addition, you don’t want the user to collect credit card information due to security concerns.
Following the screen that facilitates the payment method selection (a picklist), you can build a decision that checks whether the credit card information for the account is on file. You can then connect the decision outcome to a screen element that displays this message: “There is no credit card information for the account on file; please pick a different payment method.”
If you have a process that collects the credit card information from the account contact in a secure way, you can ask the user to decide and trigger that process based on the user’s selection.
If you don’t want a standalone error screen, you can mimic the validation error messages using display text components in screen flow.
How do you do that:
- Create an ErrorMessageTextVar resource.
- Create a decision after the screen subject to the error check and build the error outcome criteria: “Yes Error”
- Add an assignment on the “Yes Error” path and assign to the ErrorMessageTextVar an error message like “Please correct the error and resubmit.”
- Add a display text component on the screen where the check occurs and add ErrorMessageTextVar. You can change the color of the font to red. Remember; the message will only be displayed if the assignment occurs.
- Connect your assignment step to the screen element, creating a loopback for when the error condition holds true.
If you want to avoid your user having to reenter all the information, work with a record variable, assign the values of your screen components to the record variable fields, and set the default values for the screen components to the record variable field values. If done correctly, the screen will prefill the information that the user entered before the error occurred.
You can still use fault paths for the cases you cannot think of and lead them to a catch-all error screen. If you want to make sure all the database commits will be rolled back when you experience an error, use a roll-back element right before this catch-all error screen and wherever needed in your flow.
P.S. Originally published on 02/21/2022.
Read the previous issue of the newsletter here.
Read the next issue of the newsletter here.
Subscribe to the weekly educational Salesforce Flow Tips newsletter here.