Entry Conditions and Run-When-Updated Criteria

Why This Topic Matters

Record-triggered flows are the backbone of modern Salesforce process automation. With Workflow Rules and Process Builder retired, every automation that reacts to a record being created, updated, or deleted now lives in Flow. The single most important design decision in a record-triggered flow is when it should run. Entry conditions and the run-when-updated setting (formally "Only when a record is updated to meet the condition requirements") control exactly that. Get them right and your flows are efficient, predictable, and safe from infinite loops. Get them wrong and you create performance problems, duplicate emails, repeated field updates, and governor-limit failures.

The Salesforce Advanced Administrator exam tests this topic heavily in the Process Automation section (roughly 20% of the exam). Questions typically present a business scenario and ask you to identify the correct trigger timing, condition logic, or why a flow behaves unexpectedly. Understanding the mechanics—not just the labels—is what separates a pass from a fail on these questions.

What Entry Conditions Are

Entry conditions are the filters you define on the Start element of a record-triggered flow. They determine whether a given record, at the moment it is saved, qualifies to enter the flow at all. If the record does not meet the entry conditions, the flow does not run for that record—no interview is created, no elements execute, and no resources are consumed.

When you configure the Start element, you choose:

1. Object – the object whose records trigger the flow (e.g., Opportunity).
2. Trigger – when a record is created, updated, created or updated, or deleted.
3. Set Entry Conditions – the field-level criteria the record must meet. You can choose None, All Conditions Are Met (AND), Any Condition Is Met (OR), or Custom Condition Logic, or write a formula that evaluates to true.
4. When to Run the Flow for Updated Records – this appears only when the trigger includes updates and at least one entry condition exists. The two choices are: Every time a record is updated and meets the condition requirements, or Only when a record is updated to meet the condition requirements.
5. Optimize the Flow For – Fast Field Updates (before-save) or Actions and Related Records (after-save).

Entry conditions evaluate against the record's values after the change being saved. You can also reference prior values using the $Record__Prior global variable in a formula-based entry condition, which gives you fine-grained control over detecting specific transitions.

How Run-When-Updated Criteria Work

This is the concept most students confuse, so study it carefully.

Option 1: Every time a record is updated and meets the condition requirements
The flow runs on every save where the record satisfies the entry conditions, regardless of whether it also satisfied them before the save. Example: entry condition is Stage = Closed Won. An Opportunity is already Closed Won. A user edits the Description field. The record still meets the condition, so the flow runs again. This is appropriate when the flow must keep a value in sync (for example, recalculating a field every time a Closed Won opportunity changes), but it is dangerous for one-time actions like sending an email or creating a task, because those actions will repeat on every edit.

Option 2: Only when a record is updated to meet the condition requirements
The flow runs only when the record did not meet the entry conditions before the save and does meet them after the save. In other words, it detects the transition from false to true. Using the same example, the flow fires when Stage changes from Negotiation to Closed Won, but not when a Closed Won opportunity's Description is edited. This is the direct equivalent of the old Workflow Rule evaluation criterion "created, and any time it's edited to subsequently meet criteria" and the Process Builder checkbox "Do you want to execute the actions only when specified changes are made to the record?".

Important behavioral details:

• On record creation, there is no prior state, so a new record that meets the entry conditions always enters the flow under either option.
• Option 2 requires at least one entry condition. If you set entry conditions to None, the choice is not offered because there is no condition to transition into.
• Option 2 effectively uses the ISCHANGED concept behind the scenes, but it evaluates the entire condition set, not an individual field. If any part of the combined logic was false before and the whole logic is true after, the flow runs.
• Formula-based entry conditions can use ISCHANGED(), ISNEW(), PRIORVALUE(), and $Record__Prior for more precise control, such as running only when Amount increased by more than 10%.
• In a before-save flow, entry conditions still apply, but $Record__Prior is available and no DML is required to update the triggering record.

Why Entry Conditions Improve Performance

Salesforce recommends filtering as early as possible. When a record fails entry conditions, the flow interview never starts, saving CPU time, SOQL queries, and DML. Compare this to a flow with no entry conditions and a Decision element as the first step: every single save creates an interview, consumes resources, and counts against limits, only to exit immediately. In a bulk data load of 10,000 records, this difference is substantial. Entry conditions also reduce the risk of recursion. A flow that updates the triggering record with Option 1 can re-trigger itself; with Option 2 the second save usually does not represent a false-to-true transition, so the loop stops.

Common Design Patterns

• One-time notification (email, Chatter post, task when a Case is escalated): use Option 2 so the notification fires once at the moment of escalation.
• Field synchronization (keep a rollup-style field current on all active records): use Option 1 so each relevant edit recalculates.
• Detecting a specific field change regardless of value (e.g., whenever Owner changes): use a formula entry condition with ISCHANGED({!$Record.OwnerId}).
• Threshold crossing (Amount moves above 100,000): entry condition Amount > 100000 with Option 2.
• Preventing re-execution: add a checkbox field (e.g., Welcome_Email_Sent__c = false) to the entry conditions and set it to true inside the flow.

Troubleshooting Scenarios the Exam Likes

"The flow sends duplicate emails every time a user saves the record." The cause is almost always Option 1 on a flow that performs a one-time action. The fix is to switch to Option 2 or add a flag field.

"The flow doesn't run when the record is edited, even though it meets criteria." The record probably already met the criteria before the edit and the flow uses Option 2. If the business wants every qualifying edit, switch to Option 1.

"The flow runs on new records but we only wanted it on updates." Check the trigger setting; created or updated includes creation. Change to updated only.

"The flow hits a limit during data loads." Move Decision logic into entry conditions so non-qualifying records never start an interview.

Exam Tips: Answering Questions on Entry Conditions and Run-When-Updated Criteria

1. Look for frequency words. If the scenario says "once," "the first time," "when it becomes," "when it changes to," or "upon reaching," the answer is Only when a record is updated to meet the condition requirements. If it says "every time," "whenever," "always," or "keep in sync," the answer is Every time a record is updated and meets the condition requirements.

2. Map legacy terminology. The exam may describe requirements in Workflow Rule language. "Created, and any time it's edited to subsequently meet criteria" = Option 2. "Created, and every time it's edited" = Option 1 with the condition. "Created" only = trigger on create only.

3. Recognize the duplicate-action symptom. Repeated emails, tasks, or Chatter posts after minor edits point to Option 1 being used where Option 2 was needed. This is one of the most frequently tested scenarios.

4. Prefer entry conditions over Decision elements. When a question asks for the most efficient or best practice approach, the answer that filters at the Start element beats the answer that uses a Decision element inside the flow. Salesforce's own well-architected guidance says this explicitly.

5. Remember creation always qualifies. If a question asks whether a newly created record that meets conditions will enter a flow set to Option 2, the answer is yes. There is no prior state to compare against.

6. Know when the option is hidden. If a question mentions the "when to run for updated records" choice is not visible, the cause is either no entry conditions defined or the trigger is set to create-only or delete.

7. Use formulas for change detection. When the requirement is "when a specific field changes" rather than "when a condition becomes true," the best answer involves a formula with ISCHANGED or a comparison between $Record and $Record__Prior.

8. Watch for recursion clues. A flow that updates the same record it was triggered by, combined with Option 1, is a recursion risk. The correct remediation answers include switching to Option 2, adding a flag field to the entry conditions, or using a before-save flow for same-record field updates.

9. Eliminate distractors systematically. Wrong answers often propose Apex triggers, scheduled flows, or Process Builder for problems that entry conditions solve declaratively. The exam favors the simplest declarative solution that meets the requirement.

10. Read the whole condition set. Option 2 evaluates the combined logic, not one field. If a question combines multiple AND conditions, ask whether the entire set was false before and true after. That determines whether the flow fires.

Summary

Entry conditions decide which records enter a record-triggered flow, and the run-when-updated setting decides how often an updated record may enter. "Every time" fires on any qualifying save; "only when updated to meet" fires solely on the false-to-true transition. Filtering at the Start element improves performance, prevents duplicate actions, and reduces recursion. On the exam, read for frequency language, translate legacy Workflow Rule phrasing, recognize duplicate-action and non-firing symptoms, and always favor the declarative, early-filtering solution. Master these distinctions and the process automation questions become some of the most predictable points you can earn.