A record-triggered flow allows your business to automatically perform actions in Salesforce, in the background based on Create, Update, or Delete Record Events. This significantly reduces the amount of time that your business users will spend performing repetitive tasks, and also reduces the risk of human error due to the fact that the system is performing tasks exactly the same way every time.
It’s very important to make sure your business has a Salesforce Flow Design Strategy when working with record-triggered flows to ensure that maintenance, enhancements, and future troubleshooting isn’t a large task.
What is a Salesforce Flow Design Strategy?
When building record-triggered flows in your org, you will want to make sure you are building according to best practices. With legacy tools and Apex, this has been a straightforward process: Ensure you are creating a single Trigger per object when writing Apex Triggers, and create a single Process per object when working with Process Builder.
With record-triggered flows, there isn’t one best practice, but two. This introduces both freedom and an opportunity to plan for the future of your business. Creating a Salesforce Flow Design Strategy allows you to create record-triggered flows that follow a consistent design language across your entire org.
Having a Flow Design Strategy means that if someone other than you needs to update a historic flow, create a new flow, or start digging around to see which flow has triggered a specific action, they will have a great starting point. If they are updating a flow or troubleshooting, they will know the best place to begin. If they are creating a new flow, they can follow the Flow Design Strategy to ensure their design aligns with the rest of the automations in your org.
Recap: Record-Triggered Flow Best Practices
I have previously talked about the best practices when it comes to the number of record-triggered flows you should create per object within your Salesforce org. There has been a lot of discussion surrounding the best method to follow in recent times, particularly after the Migrate to Flow tool was released and Salesforce put together a plan to retire the workflow rules and Process Builder tools. Flow will be used to replace these legacy tools.
Option 1: Rule of Three
This option consists of having a maximum of three record-triggered flows per object:
- Create/Update (Before)
- Create/Update (After)
- Delete (Before)
Ultimately, all of your functionality that is triggered based on actions that occur within a particular object can be executed using just these three flows. You can then use Decision logic to split up your Flow Actions and only apply specific functionality to records meeting certain criteria.
The beautiful thing about this method is that all the functionality that is occurring for a specific event is contained within a single flow. This makes troubleshooting/investigation significantly easier as you are able to see everything on a single Flow Canvas. If your business is having issues where an action is being executed against a record and changing a value, for example, you can simply run a Flow Debug on the two Flows and you will be led to the spot that is causing the issue.
Option 2: Multiple Small Flows (with Entry Criteria)
This option consists of creating multiple record-triggered flows and using the entry criteria to limit the number of records that will trigger it. This reduces the number of times a flow is called, and leads to performance improvements during flow execution.
Unlike Option 1, you will be able to use the Flow Trigger Explorer to set the order of execution of your flows, rather than having a single flow with ordered functionality within it.
This method allows you to increase performance, particularly regarding orgs with a lot of records and triggering a lot of actions. One key consideration when working with the Multiple Small Flows option is that if you are working with an object and will need to update its child records frequently across multiple flows, you will need to use a ‘Get Records’ element inside each and every Flow that is called for a single Action, which all count toward your governor limits.
Considerations for Both Options
| Rule of Three | Multiple Small Flows | |
|---|---|---|
| How can I control the Order my actions are triggered in? | Within Flow (Use Decision Criteria to filter records out). | Flow Trigger Explorer / Trigger Order value on Flow. |
| What performance considerations should I make? | Your Flow will be triggered by all Record events (Create, Update, or Delete). Whether or not it performs one or all actions, the Flow will be called. Any child records can be collected at the beginning of the Flow and reused for each scenario within the Flow (no need to call the ‘Get Records’ Element multiple times). | Your Flows will only be called by Records that meet the criteria. That being said, if you use a ‘Get Records’ Element across multiple Flows to collect the same data set, it will be called once per Flow that is triggered. |
| How many elements can my Flow execute at runtime? | The limit is 2,000 executed elements at runtime per Flow. This can cause issues depending on the level of complexity of your Flow if you are combining them together using the Rule of Three. | The limit is 2,000 executed elements at runtime per Flow. |
| How many Flows per type can I have? | If your org is Essentials or Professional, you can have up to five Flows per type, active or not. This means you are limited to just five Record-Triggered Flows within your org. The Rule of Three would serve you best in this scenario, as the number of Flows you will need is lower. Both the Rule of Three and Multiple Small Flows options would work for Enterprise and above. | If your org is Essentials or Professional, you can have up to five Flows per type, active or not. This means you are limited to just five Record-Triggered Flows within your org. The Rule of Three would serve you best in this scenario, as the number of Flows you will need is lower. Both the Rule of Three and Multiple Small Flows options would work for Enterprise and above. |
What Else Should Be In a Salesforce Flow Design Strategy?
Your business’s Flow Design Strategy shouldn’t just consist of a structured way to design, build, and read record-triggered flows, you should also consider how your flows of all types should be built as well.
Consider screen flows, for example. When enhancing the User Interface for your org you should do so in such a way that your users will feel at home whenever they interact with a new screen flow they haven’t used before. Salesforce themselves are heavily focused on making sure their product experiences are uniform and intuitive, which is why they developed their own design strategy/system called the Salesforce Lightning Design System (SLDS).
Your Flow Design Strategy should also cover things like naming conventions of Resources, Elements, and Variables. This way, your flows will not only be structured similarly, but each of the individual building blocks of your flows will also follow the same patterns. Your future self, and any other developers who work on flows in your Salesforce org in the future, will thank you!
Summary
Creating a Flow Design Strategy to guide the build of your record-triggered flows for your business is going to make your long-term Salesforce Flow game a lot easier. Whether you are creating new flows and want them to follow a specific structure, are editing existing flows and want to be able to easily find the right flow or portion of the flow to update, or are troubleshooting a flow and want to find the issue quicker, your business will gain value from the Flow Design Strategy that you have in place.
Comments: