One Big Record-Triggered Flow or Multiple?
The question of whether to construct a single, all-encompassing record-triggered flow or to deploy multiple, specialized flows is a recurring topic of discussion amongst Salesforce enthusiasts and experts alike. Further complicating this debate is the consideration of subflows and their role in the architecture of Salesforce automation. Here is a brief disclaimer before we dive deeper: the answer is not one-size-fits-all. I approach this topic with a flexible mindset, understanding that what works in one scenario may not be the best solution in another. My stance on this is far from dogmatic, and I believe there’s merit in examining each use case on its own terms. In this discussion, I won’t suggest that deviating from a prescribed method is erroneous, but rather I aim to shed light on the nuanced decision-making process behind structuring flows effectively.
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:
AND
({!$Record.RecordType.DeveloperName}=”Sales”,
NOT(ISBLANK({!$Record.ContactId})),
OR(
ISPICKVAL({!$Record.Status},”Scheduled”),
ISPICKVAL({!$Record.Status},”Confirmed”)
)
)
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.
Explore related content:
6 Comments