---
title: "Flow entry conditions and the setting that stops duplicate runs"
url: "https://trailassembly.com/flow-entry-conditions/"
topic: "Flow and Automation"
published: "2026-09-09T11:11:53+00:00"
updated: "2026-10-06T13:51:25+00:00"
---

# Flow entry conditions and the setting that stops duplicate runs

**The quick version:** entry conditions decide which records get into the flow, but the setting that stops the flow running over and over sits directly underneath them. It is **When to Run the Flow for Updated Records**, and you want **Only when a record is updated to meet the condition requirements**. On the permissive option, the flow fires on every update where the conditions happen to be true — including the update your own automation just made.

That is the whole bug in most cases. The conditions themselves are correct, they read correctly in Flow Builder, and they will keep reading correctly while the flow runs three times per save.

## The two options, and what each one actually evaluates

| Option | What it evaluates | Runs when the record already met the conditions? |
| --- | --- | --- |
| Only when a record is updated to meet the condition requirements | The record’s state before the save and after it. The record has to cross from failing to passing. | No |
| Every time a record is updated and meets the condition requirements | The record’s state after the save only. | Yes, on every single update |

The second option is a filter, not a trigger condition. It answers “is this record interesting right now”, which is true for as long as the record sits in that state. Every save on that record for the next two years is another qualifying event.

## Why the permissive option multiplies executions

Any second save on the record puts it back through entry evaluation. There are more sources of second saves than most orgs realise:

- An [after-save flow](https://trailassembly.com/before-save-vs-after-save/) on the same object that updates the triggering record.

- An Apex trigger that writes back to the record.

- A still-active Workflow Rule field update.

- A roll-up or cross-object flow that touches the record from the other side of a relationship.

- A user hitting Save twice, or an integration doing an [idempotent](https://trailassembly.com/callout-retries-and-idempotency/) re-post.

On the strict option, none of those re-fire the flow, because the record was already meeting the conditions before that save. On the permissive option, all of them do. Duplicate emails, duplicate Tasks, and doubled counters usually trace back here rather than to anything in the flow’s logic.

## The transition rule is stricter than the label suggests

With the strict option selected, the condition requirements you chose change meaning. They stop describing the record and start describing a crossing:

- **All Conditions Are Met (AND)** — the record must go from failing at least one condition to meeting all of them.

- **Any Condition Is Met (OR)** — the record must go from meeting none of the conditions to meeting at least one. If it already met one, adding a second does not fire the flow.

- **Custom Condition Logic Is Met** — your expression, such as `1 AND (2 OR 3)`, must flip from false to true.

Here is the tradeoff, and it is a real one. Take an Opportunity flow with the condition `Stage equals Negotiation/Review`. A rep moving the record from Prospecting to Negotiation fires it. That same rep editing Amount an hour later, still in Negotiation, does not — the expression was already true, so nothing crossed.

If you wanted the flow to run on that Amount edit, the strict option is the wrong tool and no amount of rewriting the conditions will fix it. Switch to the permissive option and add `Amount` with the **Is Changed** operator, so the condition itself describes the change rather than the state. You are now responsible for making sure that change test excludes your own writes.

## Scheduled paths require the strict option

If you plan to add a [scheduled path](https://trailassembly.com/flow-scheduled-paths/), the decision is made for you: scheduled paths are only available when **Only when a record is updated to meet the condition requirements** is selected. Salesforce’s guidance also warns that change detection along a [scheduled path](https://trailassembly.com/flow-scheduled-paths/) is unreliable — a Decision element on a scheduled path testing **Is Changed = true** does not work, because the path runs in a later transaction with no prior record state to compare against. Do your change test on the immediate path and pass the result forward in a variable.

## Formula entry conditions

In the Start element, set **Condition Requirements** to **Formula Evaluates to True** when the row-based builder cannot express what you need — arithmetic across fields, a comparison against a calculated value, or a change test you want stated explicitly.

Record-triggered flows support the same change functions as [workflow rules](https://trailassembly.com/migrate-workflow-rules/), with `$Record` in place of the object name:

```apex
ISCHANGED($Record.StageName)

AND(
  ISCHANGED($Record.Amount),
  $Record.Amount > PRIORVALUE($Record.Amount),
  NOT(ISNEW())
)
```

None of `ISCHANGED`, `ISNEW`, or `PRIORVALUE` are available in a flow triggered when a record is deleted. `ISNEW()` takes no arguments and needs no rewriting when you copy a formula across from a workflow rule.

My preference: once you are writing a formula, put the change test inside it rather than depending on the radio button below to narrow things down for you. A formula is something the next admin can read. “Only when a record is updated to meet the condition requirements” is a behaviour they have to already know about, and it is two clicks deep in a screen most people scroll past.

## How to prove the conditions exclude what you think

Reading the conditions is not testing them. Three checks, in increasing cost:

1. **Flow Builder Debug.** Open the flow, click Debug, pick the triggering record, and leave **Skip start condition requirements** unchecked. If the conditions do not admit your record, the debug run tells you so instead of running the flow anyway. For update-triggered flows, set the field values you want the save to change so that the prior-value state is populated realistically.

2. **Count the interviews in a debug log.** Setup → Debug Logs, add a trace flag on your user with the Workflow level at FINER, reproduce the save, then search the log for `FLOW_START_INTERVIEW`. One entry per user action is the target. Two entries means the conditions admitted the record twice, which is the measurement, not an inference from the flow diagram.

3. **Test the case you think is excluded.** Take a record that already satisfies the conditions and update an unrelated field on it. On the strict option nothing should happen. This is the single most useful test, because it is exactly the scenario the permissive option gets wrong, and it is the one nobody runs.

Then repeat at volume. Load 200 records through Data Loader where every row already meets the conditions, and check **Setup → Paused and Failed Flow Interviews** afterwards. Entry conditions that admit 200 records where you expected 3 turn a design problem into a governor limit exception, and that is the version your users will report.

## Frequently asked

### Does the strict option apply to record creation too?

No. The setting is specifically about updates. The label says so. A create either meets the conditions or it does not, and there is no prior state to cross from, so a qualifying create always runs the flow.

### Do entry conditions save any resources if they fail?

Yes, and this is the main argument for pushing logic into them. When a record fails the entry conditions, no interview starts. Nothing is evaluated, no CPU is spent on the flow, and nothing shows up in the interview logs. The same test written as the first Decision element costs you a started interview on every record.

### Can I use Is Changed in entry conditions on a create-or-update flow?

You can select the operator, but on a create there is no prior value to compare, so do not rely on it to distinguish the two events. If a create and an update need different handling, two flows are clearer than one flow with a Decision at the top, and they let you set the update flow to the strict option without affecting creates.

### Why did my flow start running twice after someone else deployed a change?

Something new is writing back to the record, and your permissive entry conditions were always going to admit that write. Check the [Setup Audit Trail](https://trailassembly.com/who-changed-this-field/) around the date it started, and list every active flow, trigger, and Workflow Rule on the object.

### Is there a downside to the strict option?

One, and it catches people out: subsequent genuine changes are ignored while the record continues to meet the conditions. If your automation needs to respond to repeated edits within the same state, you need the permissive option plus an explicit change test, and you then have to keep your own writes out of it.

---

*Reference: “How Entry Conditions Work in Record-Triggered Flows”, “Record-Triggered Flow Considerations”, and “Use [ISCHANGED](https://trailassembly.com/flow-ischanged/), ISNEW, and PRIORVALUE in Record-Triggered Flow Formulas”, Salesforce Help.*

---

Source: https://trailassembly.com/flow-entry-conditions/
Trail Assembly — independent Salesforce write-ups.