I will revisit one of the most popular debates on flow: Do we create one giant record-triggered flow or multiple flows? And should we use subflows?
Here is a little disclaimer: It depends. I’m not too fond of rigid rules, and I am not here claiming you are doing something wrong if you do things differently.
Now that I got that off my chest, I do have an opinion on the topic:
Asking the right question is very important. Is “How many flows should we build per object?” a good question? Generally, I don’t think so. We should ask ourselves: How can I build automation that does not waste system resources, is easily readable, and is easy to maintain?
My priority when I build my flows is that my build should not run unnecessary automation. My most important objective is not to trigger automation when it does not need to run.
In a complex Org, you quickly realize that yields multiple flows per object. When you look at the three tasks that can be performed in one big record-triggered flow, they rarely need to run all in the same scenario.
Now that I told you I heavily use my start element criteria, do I use the formula entry criteria or the line editor with AND/OR operators?
Here is my experience: I often see record-type usage in fairly complex Orgs. I’m not particularly eager to hardcode RecordType Ids in my start element criteria. I prefer to use DeveloperName or Name over Id. And these are only available in the formula editor. So I often end up using the formula entry criteria.
Some of these formulas get very big. But I will give you a simple example:
Now let’s get to the other popular topic: Subflows. I recently inherited work that another Salesforce partner did. They did a good job but used subflows in many of their flows. I found the outcome very hard to read and understand. The back-and-forth review left me confused and tired.
I only use subflows if I know I will reuse the logic in another flow.
This post was originally made to LinkedIn on June 19th, 2023.
Read the previous post: Emojis ❤️ and Dreamin’ Events 👌