Flows are a Salesforce administrator’s best friend. Workflow Rules and Process Builders are an inefficient thing of the past. Flows allow you to deliver automation painlessly and effectively for a variety of dynamic use cases fast.
Some advantages of Flows
While there are numerous benefits to Flows, I like to categorize the major advantages of Flows over other Salesforce automation tools into the following categories:
Logic & Execution
- More flexible allowing you to build more complex automation without code.
- Mix and match functional modules built with Flows and Lightning Components facilitating interoperability and re-use.
- Advanced templating using text templates, variables, and formulas.
- Query and update unrelated records.
User Interface
- Allows user interaction using screen elements.
- Embed Lightning Components within a Flow, or a Flow within a Lightning Component.
Performance
- More performant than Process Builders.
- Can update record fields Before Save, similar to before insert and before update Apex Triggers.
- Handles record sets with bulk save capability.
Need for Error Handling
With great power comes great responsibility. Flows are a powerful tool that are part of the Salesforce’s order of execution. To enable growth and set yourself and your Salesforce org for success, flows should be designed to not cause disruption down the road due to individual flows stepping on each other’s toes as well as to work well with other tools like Apex triggers, Validation Rules, and more.
Flow Error Handling Design Patterns
Let’s look at the most common design pattern for error handling in Flows independently for Screen Flows and Record-triggered Flows. In the following examples, we will assume that the exception we are trying to handle gracefully is caused by an underlying validation error.
Screen Flows
By default, if a Screen Flow fails due to any reason, the user is presented by a generic unhandled exception message that is ugly and should be avoided. A detailed design pattern that can be implemented to handle exceptions for Screen Flows is in an upcoming blog post.
Record-triggered Flows
By default, if a Record-triggered Flow fails at record creation or during update, the user who triggered the record modification may or may not even know that an error occurred and all automation that was designed may or may not have completed correctly resulting in data inaccuracy, data loss, and more. A detailed design pattern to handle exceptions for these types of flows can be found in an upcoming blog post.
Comments