It's here! Flows running on API Version 59 and above now have access to a very powerful element called the Custom Error element. Why is this such an improvement to Flow? Before API 59, some seemingly simple business requests would take more custom development or a far greater level of effort. One of the best use cases for the new tech is to effectively implement Validation rules for related objects. For instance, Let's take a look at a an example problem:

Before API 59, this business request could be handled in a few ways:

  1. You could have written an Apex trigger to throw a custom error
  2. You could have created a custom checkbox field on the Opportunity object that would be marked true when all child Tasks are completed. You'd then have to write automation to populate that checkbox
  3. You could have forced an uglier error message in Flow via installable components

Now, with the new Custom Error element, you can write your Flow as simply as this:

First, we would define our input criteria (any Opportunity where the stage is updated to Closed Won or Lost)

Then, we will look for a Task record that should throw an error.

💡
We only need to select the option for a single Record to be retrieved by the Get Records element. In our use case, it doesn't really matter if there is 1 incomplete Task on the Opportunity record, or 100. However, if you wanted to give more details in your error message, you can always assign the count of your returned collection to a variable to show your user how many Tasks they will need to complete before moving the status!

Then, we will check if any records were retrieved.

Finally, if we find incomplete task records, we will throw out custom error.

Presto! We have now automation written to effectively perform a validation rule on related records. In the UI, that error looks something like this:

Some considerations before flooding your Org with these helpful banners:

  1. Use this functionality wisely: While including these business rules might help keep your data squeaky clean and your business processes airtight, flooding your user with these error banners will likely negatively influence the experience of your users
  2. When possible, use Custom Error elements in Before Context Flows: The above use case was able to be written in the Before Context as the Custom Error elements are able to be called from Flows of this context. Keeping these Flows in the before context should greatly reduce the performance impact of these types of Flows (in some benchmark evaluations, Before context Flows are cited as being several times faster than their After context counterparts). See the Salesforce Architect Guide
  3. Be descriptive, but try and stay concise with writing error messages: Write messages that clearly detail the issue and what the user needs to do to resolve it. Vague errors like 'Review the changes you've made' might not be descriptive enough for even the most savvy user to know exactly what they need to do to send the record through
  4. Use translations where necessary: While not explicitly stated, Custom error messages are directly translatable in Translation Workbench.

Using the new Custom Error Element in Salesforce Flow