In a record-triggered flow on a custom object, can I use the Custom Error element to stop a record from saving and show an error message to the user, similar to a validation rule?
My scenario: on the Loan object, when a checkbox field changes from false to true, I want the flow to check whether at least one related child record exists (the child has a lookup field to the Loan). If no child record exists, the save should be blocked with an error message.
Please confirm:
- Is the Custom Error element available in both before-save (Fast Field Updates) and after-save (Actions and Related Records) record-triggered flows?
- Which type is recommended when the flow needs a Get Records element to look up related child records?
- Does a Custom Error roll back the entire save, including any other changes the user made to the record?
- Can the error be shown on a specific field, or only at the top of the page?
- Are there any limitations when the record is saved from a custom Lightning component rather than a standard record page?
Yes, you've got the right idea for what the Custom Error element is used for.. Use it to throw a custom exception to the user where the validation logic is not supported in validation rules. Your use-case is a good fit.
- Yes, you can now use the Custom Error element in both before-save flows and after-save flows.
- You can use a Get Records element in either context. This should not determine your approach.
- Yes, transactions are atomic, by default, so the entire transaction (save) is rolled back when an exception is thrown, including any other changes.
- Errors can be added to a specific field.
- No, there are no inherent limitations to this feature when the process is invoked from a lightning component. The component would need to handle the exception and determine what to do with it, though. To your question #4, displaying a field-level error next to its field would become your responsibility.
For your particular use-case, one before/after context consideration might be whether or not the first child record can be inserted in the same transaction as the checkbox value is changed. If you have other field changes that would cause your child records to be created via the Loan's after-save automation, you might have an argument to run the validation in an after-save context, too... sequenced after the child records have the potential to be provisioned. If you can safely assume that the child records will already be there before the checkbox is checked, then throwing the Custom Error in a before-save context should save unnecessary processing and throw a bit faster.
