For Everyone

When and how should I use entry criteria VS decision elements in Flows? #admins

4 min read
CloudAnswers photo

Both entry criteria and decision elements are great ways to filter records down to get exactly what you need, but there is a time and place for each. First, let’s take a look at their strengths and limitations. Then we’ll dive into how and why to use each with a business problem that is solved by using both.

Strengths and limitations:

Entry Criteria:


  1. Triggers the flow
  2. The first criterion to fire which helps filter down records
  3. It can evaluate multiple values


  1. Can only reference the object that triggered the flow
  2. Can only be used once
  3. Can only go in one path

Decision Elements:


  1. Can reference multiple objects
  2. Can have multiple values
  3. Can split into many different paths


  1. Can only evaluate records that have already been filtered down
  2. Cannot choose when to fire the flow, before VS after record save
  3. Cannot choose when to run, every time a record is updated VS when it meets requirements

The scenario:

A local non-profit has asked you to help them track whether or not someone is in their system as a donor. In order to do that they have a custom picklist field on the Account object with the following values, Donor, Non-Member, and Partner. When the donor status is selected, they want an Opportunity to automatically be created with details from the Account. However, if the Account already has one or more related opportunities, an opportunity record should not be created. The creation of the Opportunity record is to track the new donor, and the organization also wants an email alert to be sent to the new Donor thanking them for their patronage.

To satisfy this request, start by creating a record-triggered flow on the Account object. To start, you use the entry criteria to filter down the records. Yes, it is possible to gather all Account records and then filter down using a decision element later, however, that is inefficient and not best practice. Setting the entry criteria to “When a record is updated” and then filtering down to when the Member Status field = Donor will provide you with the exact record you need.

Once a record has been updated to meet the criteria, the following logic will fire. The first get record element collects the AccountId and stores it in a variable, aptly named ‘AccountId’. The second element uses the AccountId variable to see if any opportunities exist that are related to the Account record that triggered the flow.

Once the flow has collected all of the information, it then passes into a decision element. If the AccountId on any Opportunity in the system equals the current RecordId, then the flow will do nothing. That’s an ‘Existing Opportunity’. If no Opportunity is found then the flow will go ahead and create a new Opportunity record and relate it to the Account record that started the flow.

Why don’t you just check for an existing Opportunity in the entry criteria? It might sound more efficient to do this all in one step, however, there are a few issues with that approach. The first and largest being able to filter down to specific Opportunity records related to the Account is just not possible in the entry criteria. Entry criteria are just that, criteria to enter the flow. It has its limitations, such as only being able to reference data from the record that started the flow, and no other object. It also lacks any way to split into different paths based on criteria — this is where the decision element comes in. The decision element is great because it compliments the shortfalls of entry criteria by allowing you to reference any and all records and objects that came before it in the flow. By utilizing a decision element, I was able to filter down Account records without Opportunities, which is not possible using entry criteria alone.

As you can see, both entry criteria and decision elements have their time and place, and when used together they can be powerful teammates to help build a sophisticated Flow.

CloudAnswers photo

About CloudAnswers

Salesforce apps, powerful components, custom development, and consulting. Our experienced team helps you to create and modify workflow processes in salesforce.

Related Articles

For Everyone

AppExchange Review Series

As a long time Salesforce partner (since 2008), on both the consulting and AppExchange side, we realized we have a wealth of experience in building, installing, configuring, and using AppExchange apps. Our consulting customers often come to us with questions about which app would solve a particular problem, and as part of our AppExchange business we are often trying apps to learn what to do (and not to do) when building our own.

July 24, 2024

3 Min Read

For Everyone

Product Launch: CloudAnswers Shop Builder

Are you looking for an easy way to launch an ecommerce shop? Our new app, Shop Builder, is now in public beta! We’re looking for companies that want to build an online shop but don’t want to spend thousands building it out.

April 12, 2024

5 Min Read

For Everyone

A Day in the Life of a Project Manager at CloudAnswers

I'm Emily, and I've been a project manager at CloudAnswers for the last two years. It can be a nebulous role, but I like to say I act as a bridge between the product vision and tangible results, whether that is building a custom app for a client or one of our own Salesforce products. My typical day revolves around managing tasks, ensuring progress, and maintaining standards while adhering to project timelines.

March 22, 2024

5 Min Read