Can You Start With a Decision Inside Your Record-Triggered Flow?
When you build a record-triggered Salesforce flow, you may need to use the decision element to differentiate the path your flow takes based on conditions. Before we dive further into best practices, let’s take a look at what the decision element in flow is and what it does.
Decision Element
Salesforce Flow Decision Element is a logic component used in Flow Builder to route your flow’s path based on specific conditions. Think of it like an “if/else” or “switch” statement in programming—it lets you control what happens next depending on the data or situation.
What It Does: The Decision Element evaluates data from the flow (like record fields, variables, or formulas) and then directs the flow down a specific outcome path depending on which conditions are met.
Key Parts of a Decision Element:
- Label & API Name: A name for easy reference.
- Outcome(s): These are the different paths the flow can take. Each outcome has a Label and Condition.
- Default Outcome – A fallback path if none of the other outcomes match.
Let’s say you have a flow that processes a case. You can use a Decision Element to check the case priority: Outcome 1 will send the case to the Escalation Queue, if Case Priority = High. Outcome 2 will send the case to the Standard Queue If Case Priority = Medium or Low. The Default Outcome will log an error, send a notification or do nothing.
Record-Triggered Flow
A record-triggered flow is a type of Salesforce Flow that automatically runs when a record is created, updated, or deleted. It’s often used to automate tasks like updating related records or sending notifications.
Record-Triggered flows are subject to a popular debate: Experts have varying recommendations on how many record-triggered flows are optimal on a given Salesforce object (e.g. Case).
The best practice recommendation and the anti-pattern definition here will be highly dependent on this approach.
One Record-Triggered Flow or Many on a Single Object?
My recommendation is that you can and should have multiple record-triggered flows on a single object, if you can optimize the start conditions to ensure only a small subset of the record-triggered automation logic is executed for a particular record. If you try to combine all the logic into a single flow, you will not be able to tighten your start element conditions effectively, instead you will resort to using decisions to differentiate paths inside the flow.
Why Starting Your Record-Triggered Flow Can Be an Anti-pattern?
Considering all these factors listed above, using a decision that follows your record-triggered flow start element most likely points to an inefficient design: You use decision outcomes to differentiate business logic, when you could separate these paths into multiple record-triggered flows and add these conditions to the start element.
Let me explain.
You have three record types for the case object representing Hardware, Software and Other. You have a fairly sophisticated record-triggered flow to process new Cases. For the Other record type your flow does not do anything.
If the solution in this case is to use a decision element inside your flow connected to the start element to check the record type, then you should consider separating this record-triggered flow into three different flows.
And if some of the business logic repeats for more than one record type, you should consider leveraging subflows.
Why Is This Design More Efficient?
There is a system overhead associated with starting a flow execution. If you execute your flow and evaluate conditions in the decision element, you already used cloud resources. If you can stop your flow from executing, you won’t use any resources. Start element conditions stop the flow from executing.
Can you achieve this just by tightening your start element conditions and excluding the Other record type? Sure, you can. Is the use case always this straightforward. Not, really. For more complex use cases, it may make sense for you to split your flow into multiple record-triggered flows.
Conclusion
While using a decision right after your start element may make sense in certain situations, it is a potential anti-pattern you should watch for. If this is a flow somebody else built, or you built ages ago, seeing this pattern should prompt you to inspect and reevaluate the design in this flow.
Leveraging multiple record-triggered flows on a single object with the support of flow trigger explorer and the execution order setting can be a very good idea in these situations. If your business logic repeats in your triggered automation, you should consider leveraging subflows for easier maintenance.
This post is part of our Best Practices series! Click HERE to see the rest of the posts.
Explore related content:
A Comparative Look at Flow Decision Elements in Salesforce
How to Use the Action Button Component in Screen Flow
One Comment