A few months ago I watched a Webinar in which the speaker advised that we should only ever build one Record Triggered Flow per Object per Context. Meaning a Object could have a maximum of 3 Record Triggered Flows (1 x Before Save, 1 x After Save, and 1 x After Deletion). Since then I have been experimenting by sticking to the One Record Triggered Flow per Object per Context and I'm not sure I agree with the speaker.
With the impending retirement of Workflows and Process Builder, plus the the increased power of Flows its pretty clear that Flows will become the go to automation tool for most cases, especially with Salesforce’s focus on “Clicks not Code”. Of course there is always going to be the need for code for the most complex logic and automations but the rule of thumb should be to focus on declarative rather than programmatic solutions first.
I want you to imagine a Org which has a large number of automations, these include simple Record Naming Conventions through to some of the most complex Flow use cases you may have come across. We could certainly look at creating one Flow per Object Context with multiple Sub Flows firing from it which would give us a couple of major advantages;
We can control the Order of Execution using this method.
It encourages Reusability through using logic in Sub Flows that can be used elsewhere.
We can see all the Flows that impact an Object per Context.
While that does sound great I do question how easy it would be to manage in the future, especially if you didn’t build the original Flow and have been asked to figure out what is wrong it if it stopped working correctly. Troubleshooting a Flow with numerous Sub Flows is going to be a lot harder than finding the issue with an individual Flow, even for someone who is comfortable with Flows. And my personal view is that what we build should be as simple and robust empowering customers and clients to maintain as much of their Org as possible without us, creating complex Flows like this will discourage end users and provide a greater risk when they look to self service and fix any issues themselves.
With Flows becoming more and more powerful with every Salesforce release, the advantages of using one Flow per Object per Context are being reduced rather quickly.
There are two features announced for Spring ‘22 that have caught my eye;
Flow Trigger Order
Flow Explorer
We can now specify the Trigger Order of our Flows! This is pretty game changing and is done by assigning a numeric value between 1 - 1000 in the Trigger Order Field, Salesforce then executes Flows with the same Context (e.g. Before Save) in ascending order thus giving you control of the order of execution of your Flows! This can be done when you save your Flow.
We also have the new Flow Explorer feature which allows us to see all of the Flows for an Object on one screen in an ordered list giving us a true view of how an Object is being impacted by all of the Flows in one easy to read screen. You can launch this from the screen which contains all of your Flows, or from a Flow itself.
These two major improvements take away a lot of the argument for using only one Flow per Object per Context but still do not solve the reusability point. However, is reusability more important than creating Orgs what our clients can manage effectively without us?
I guess this, as with many other Salesforce topics, comes down to personal preference and/or company policy.
What do you think? One Flow per Object per Context or Multiple Flows per Object?