Winter '24: New way to do complex validations in Flows
Arriving in Salesforce’s Winter ‘24 release, Salesforce has shipped a new feature called Custom Error for Flow Builder that can be used to throw custom errors. This has been one of the most awaited and requested features ever since record-triggered Flows were announced.
Salesforce Developer, Technical Writer, and Entrepreneur
Sushrut is a skilled Salesforce Developer, Technical Writer, and Entrepreneur. His expertise includes front-end dev, Web3, and DevRel. He leverages technology to craft exceptional digital experiences.
Manuel Moya Ferrer is a highly skilled freelancer who serves as a technical architect, developer, and DevOps engineer. He specializes in Salesforce solutions, covering all technical aspects of their development lifecycle.
Article Highlights
The new Custom Error feature in Salesforce's Flow Builder allows admins to create complex validations similar to Apex triggers but without coding, enhancing data integrity with dynamic error messages.
Custom Error actions can be configured to display errors either as pop-ups or inline with the field, ensuring clear communication of validation issues directly where they occur.
This feature is particularly useful in scenarios where traditional validation rules fall short, such as validating data across related objects or complex discount structures.
What is a Custom Error Message?
Traditionally, to execute complex validations, Developers use Apex triggers. However, with the new Custom Error action, Admins can build complex validations and surface meaningful errors like Apex triggers.
❌
The error messages thrown by the Custom Error action are displayed in a popup window on the “Record” page or as an inline error on a specific field, depending on how the action is configured.
You can also configure this action to throw multiple errors by using just one action within which you can specify numerous errors.
Where would I use this feature?
You’d use this feature to do data validations in your Salesforce org like you use validation rules.
But this only applies to use cases that validation rules can’t achieve. Some of them include scenarios like:
Doing validations based on data available on related child objects’ records. For example, if you want to prevent the deactivation of an account if the account has any open cases.
Validating complex discounts based on region, quantity, previous orders, product bundles, etc.
Providing record ownership-related validations.
Throwing multiple meaningful errors for blank inputs on record creations and updates.
Forcing a transaction to fail to roll back the changes.
There should not be complex validation Flows. Flows should be simple, easy to read, and maintainable by admins. If the requirements are complex, this logic should be moved to Apex, which is more suitable for scaling, maintaining, and importantly, unit testing.
Harald is the Co-Founder of Hutte, bringing his vision of no-code DevOps to life. His passion enables teams and individuals to focus on what matters most – bringing value to the users they build for.
