If you were to picture a simple Flow in your head, it would look something like: do A, then B, then C. If you’ve worked with Process Builder before, that straight-line structure will feel familiar.
But real life isn’t always that straightforward. Users and customers can make different choices, processes often come with exceptions, and the next step depends on the situation. This is where Decision elements shine because they are your Flow’s forks in the road: your flow asks a question, and depending on the answer, it heads down a specific path. Decision elements give your flow the structure that transforms it from a basic checklist into something more dynamic.
The Decision Element: Outcomes and Branches
Let’s break down the Decision element. The main purpose of it is to create paths for your flow to take based on specified criteria or conditions. Each path is called an Outcome.
When you configure a Decision element, you’ll start by setting the usual fields: Label, API Name, and Description. After that, you’ll define the Outcomes. By default, Salesforce gives you two paths: New Outcome and Default Outcome.
The New Outcome is the one you configure, and it’s the first path where you’ll set the conditions. Each outcome (except the default) needs its own Label and API Name, plus the conditions that should be met for the flow to follow that path.
When setting up conditions, you’ll see three options under Condition Requirements to Execute Outcome:
- AND: all conditions must be true.
- OR: at least one condition must be true.
- Custom Logic: mix and match your condition numbers with operators like AND, OR, and NOT for more complex rules. This comes in handy if you want something like: “Close Date is this quarter AND Stage is Negotiation, OR Probability is over 80%.”
When it comes to conditions themselves, you’ll configure them by setting three things: a Resource, an Operator, and a Value.
- The Resource is what you want to evaluate, and this could be any resource in your flow, including Global Variables (like the current running user or triggering record).
- The Operator is how you want to compare that resource (could be equals, does not equal, greater than, contains, etc.).
- The Value is what you’re comparing your resource against. For example, it could be a resource in your flow holding a specific Stage name, a number, or Global Constants like True or False.
So in practice, your conditions might look like:
- [Opportunity Stage] equals “Closed Won”
- [Escalated] equals True
- [Annual Revenue] greater than 1000000
You can add as many conditions as you’d like, as there isn’t a strict per-condition limit for Decision elements. However, keep in mind that every evaluation contributes to the flow’s overall processing time, meaning the more complex your conditions, the more work the system has to do. To keep your flows efficient, try to keep your conditions straightforward and avoid unnecessary checks.
If your flow is a Record-Triggered Flow, you’ll see an extra setting called “When to Execute Outcome”. This controls when Salesforce checks your conditions, and it might be easier to identify which one you need by asking, “Do you want this to happen just once, or every single time?”
- Only when the record is updated to meet the condition requirements (the outcome runs the moment the record changes into a matching state, meaning the flow only fires the first time the record matches the condition)
- Example: Your condition reads “Case Priority equals High”. A Case’s Priority changes from Medium to High. The outcome is executed right at that change, because that’s when the condition became true.
- Every time the record is updated and meets the condition requirements (The flow fires any time the record already matches the condition and then gets updated again).
- Example: The Case is already Priority = High, and someone edits the Description field. Even though Priority didn’t change, the condition “Priority = High” is still true, so the outcome runs again.
In short, you just have to choose between “only trigger when it flips to true” and “keep triggering as long as it’s true”.
Now you’ve got your first conditional Outcome. Adding more is as simple as clicking the plus sign next to Outcome Order. Whenever you add a new outcome, you’re essentially adding another branch to your decision element. You can add as many outcomes as you need, but it’s usually best to keep them tidy so your flow stays easy to follow.
Keep in mind that order matters. Your flow evaluates outcomes from top to bottom and executes the first one whose conditions are met. So, let’s say if two outcomes could both be true, whichever is higher in the list “wins”. The good news is you can easily rearrange outcomes by dragging them into the order you want.
And if none of the conditions are met, we finally have our Default Outcome. This one’s the easiest, no conditions required! It’s like your safety net, or the “everything else” path. You can relabel it if you like, but you don’t have to configure anything for it to work.
Tips for Decision Elements
Here are a few tips to keep your Decision elements clear and reliable:
- Name outcomes clearly.
When I was first learning Decision elements, I used labels like “Outcome 1” or “Path A”. That works fine in the moment, since you already know what you’re building toward. But fast forward a few months, and trying to understand that same flow can turn into a nightmare when making sense of each path means you’d have to click into each outcome just to see what the conditions were. Save yourself (and others) the headache by using meaningful names like “Closed Won Path” or “High Priority Escalation”. Clear labels make flows easier to understand and maintain, both now and later.
- Order outcomes with intention.
The order of outcomes isn’t random, as your flow checks them from top to bottom. Be deliberate with the way you arrange them by thinking about how each condition relates to the others and making sure one branch doesn’t accidentally “steal” records meant for another. In some cases, that might mean putting very specific conditions first. In others, it might make sense to put a more common condition higher so it’s evaluated sooner. The important thing is that the order reflects your process logic, and not just the order you created them in.
- Test edge cases and every possible outcome.
When you’re setting up your Decision element, do try to think about not just the common scenarios, but all the possible ones. Every single value or scenario that could come through should have a clear path. And then ask yourself: what if none of these expected values show up? Configure the actions for your Default Outcome path as needed. It acts as a safety net to catch anything you didn’t explicitly plan for.
- Consider a Formula resource for complex logic.
If you ever find yourself stacking too many conditions into your Decision element, it might be a sign to step back. Instead, try building a formula resource that evaluates your logic in one place. This way, your Decision just has to check whether the formula returns True or False, and it saves you time reviewing complex logic and long lists of conditions later on.
Final Thoughts
Decision elements are awesome in the sense that they give processes the ability to adapt based on what’s happening in the moment.
By learning how to configure outcomes and branches, you’re giving your automations the ability to handle complexity and solve real business problems.
