How many flows should I have per object?
With Salesforce announcing the retirement of two of the most well-used tools, workflow rules, and process builder, you may be migrating your automations to flows. While doing this, a natural question may be how to structure your flows best.
But to start with, let’s look at how other automation types are structured on the platform.
Writing automations using APEX
The most powerful and complex way of creating automations on the Salesforce platform is to use code. To automate things based on actions on records, you use triggers.
The best practice for writing APEX triggers is to use one trigger per object. Then, using logic and methods, you can execute different code blocks based on your chosen circumstances.
A trigger can execute when a few record events happen; insert, update, and delete. And to provide even more control, these can be further specified to occur before or after the change has been saved to the database. Depending on what you need to automate, you must choose the right combination when you develop the trigger.
The best practice is to have one trigger that listens to all, or at least all, of the combinations of trigger events, which your automation may need. And then, by logic, direct the execution to the correct code. You can do this via simple code logic or an elaborate trigger pattern.
Automating using Workflows
In Salesforce’s history, a workflow was an early way of creating automations. These automations are pretty simple, based on criteria one or multiple actions would execute. For example, these actions could be updating a field (on the triggering object), sending an email, or sending data to a specific web service/endpoint.
This sounds simple, but it was one of the big superpowers of Salesforce and saved the users a lot of time. Of the technical nature of Workflow, you need many of them to solve automation challenges. You could not combine many workflows into one.
Workflows are always running last in the chain of events when a record is updated. They happen after the database has been updated and triggers have been executed.
Automating using Process Builder
Then Process Builder came along. Again, a more advanced automation tool compared to workflows but still more straightforward to work with than writing code. In the beginning, Process Builder had many performance issues, which kept much of the work with the more advanced automations still being done using code. But with time, Salesforce ironed out the performance issues, and we had a new and potent tool to create automations quickly.
This led to another pattern - one or two Process Builders are the only thing needed per object. Process Builder is being executed on “create” or “create & update”, which can contain multiple actions. It is possible to use formulas to know if you are in a “create” (ISNEW()) context or in an “update” context and see what fields changed (ISCHANGED()), and this could help you limit your number of process builders to one per object.
Cleaning up your Salesforce instance at this point was a good idea. If clean-up was done, workflows could be moved to process builder instead of using the new pattern. But, hey, why touch something that works and risk breaking it? After working in many Salesforce instances, the old Workflow automations stayed, but new things have been developed in process builder instead.
Automating using Flows
Now we have Flows — the latest automation engine in Salesforce. Unfortunately, I have no technical insight into what’s going on in the background. However, this seems like the same engine as Process Builder but with a new and more powerful user interface providing more capabilities to the user.
Flows is an advanced drag-and-drop system to create powerful automations.
But to get back to the post’s main topic, how many flows should you have for every object in Salesforce? Well, it depends - mainly on the size of your instance - large instances bring more complexity and may need to be split up into more parts.
Why limit the number of flows?
As the Salesforce instance becomes more customized, it is harder to maintain the automations. For example, suppose multiple automation strategies are being used; apex/triggers, workflows, process builder, flows, and with numerous instances of each automation type. In that case, getting an overview and understanding of what is going on becomes increasingly difficult.
Limiting to as few record-triggered Flows as possible per object will give you a more straightforward job. You will more quickly be able to find issues and make changes.
Three flows are all you need
We can look at when a record-triggered flow is executed to get a hint at what flow we may need. You can trigger your flows with the following events:
- A record is created
- A record is updated
- A record is created or updated
- A record is deleted
Just as with Process Builder, we can, in the flow, determine in what context we are running (created or updated) and also see what has changed. Because of this, we need two flows:
- Created Or Updated
- Deleted
But when we run a flow on any of the “create” or “updated” contexts, we can also determine if we should run before (Fast Field Updates) or after (Actions and Related Records) the data has been saved to the database. The deleted event is only triggered before the record is removed from the database. With this knowledge, we know that we will need the following scripts:
- Before Created or Updated
- After Created or Updated
- Deleted
This structure is similar to how APEX triggers are structured, but APEX triggers can be controlled even more granularly.
Use sub-flows
But you have already thought this; my flows will be massive! This is where sub-flows come in. Again, similar to coding in APEX, you do not put all your code in the trigger. Instead, you put the actual code in helper classes. The result will make your APEX trigger smaller and easier to follow and maintain.
Split your flows into sub-flows that you call from your record-triggered flow. It makes your flows smaller, easier to follow and maintain, and reusable - e.g., you can call the same sub-flows from many different record-triggered flows.
When you create a sub-flow, you can create variables of type record. These should be available for input. This way, you can feed record information from the triggering flow to the sub-flow.
You only use sub-flows in “after created or updated” or “deleted” type flows since the fast field update flows do not support it.
An alternative approach
Using only one record-triggered flow per object in large and complex Salesforce instances may be too simplified. There can be issues related to performance. Or how responsibilities are organized in the organization. Different teams are working on the same objects and will need to work in parallel and autonomously.
In this case, entry criteria can be used to limit when a flow should run. I recommend using the structure described above, with three flows but three flows per criteria. As an example, the criterium could be a specific record type.
These thoughts will help you structure your flows to make your environment easier to maintain and to continue developing features and functionality for your users.