What Entry Criteria Do

When a record-triggered flow is configured, you can specify conditions the record must meet for the flow to fire. Records that don’t meet the criteria don’t invoke the flow at all — no execution, no resources consumed.

Well-tuned entry criteria mean flows fire on 5% of records instead of 100%, dramatically reducing load on your org.

Three Places Entry Criteria Can Run

1. Trigger-Level Entry Conditions

Set when you configure the record-triggered flow. Evaluated by the platform before the flow runs at all.

Most performant. Always prefer this level when possible.

2. Decision Elements Inside the Flow

Used to route branches after the flow has started. Consume flow interviews and elements even for “no-op” paths.

Use for in-flow branching, not for “should this run at all.”

3. Manual Filter With Get Records

A query in the flow that returns records matching a condition. Expensive — uses SOQL, runs every time.

Avoid using this as a substitute for proper entry criteria.

Types of Trigger Conditions

For record-triggered flows, the trigger condition editor offers:

All Conditions (AND). All conditions must be true.

Any Condition (OR). At least one condition must be true.

Custom Condition Logic. A formula combining conditions with AND / OR / NOT — essential for complex criteria.

Formula Evaluates to True. A full formula — use for logic that doesn’t fit the clause builder.

Best Practice 1: Fire Only When Relevant Fields Change

A flow that updates the Priority field when the Account tier changes should only fire when the Account tier actually changes — not on every update.

Use the “Triggered when record is updated and meets the condition requirements” option combined with “Updated — any time a record is created or updated and meets the condition requirements.” Then in the entry criteria:

ISCHANGED([Account].Tier__c)

This filters to updates that genuinely changed the tier. Record updates touching other fields skip this flow.

Best Practice 2: Check for Non-Null Values

A flow computing from a field should only fire when that field is populated.

NOT(ISBLANK([Case].Account.Type))

Prevents wasted flow interviews on records missing the needed data.

Best Practice 3: Exclude Integration User Updates

When an integration user bulk-updates records, you often don’t want every record-triggered flow to re-run for each one. Gate your flow:

$User.IsIntegrationUser__c != true

Requires a custom user field marking integration users. Cleaner than checking UserIds directly.

Best Practice 4: Use PRIORVALUE Sparingly

PRIORVALUE(field) returns the field’s value before the update. Useful for detecting specific transitions:

AND(
  ISPICKVAL(PRIORVALUE(Status), 'Open'),
  ISPICKVAL(Status, 'Closed')
)

“Only fire when Status transitioned from Open to Closed.” Very precise.

Use sparingly because PRIORVALUE is only available in criteria for update triggers — not inserts — and can be subtle to read.

Best Practice 5: Combine With Record Type

If only one record type needs the flow:

[Case].RecordType.DeveloperName = 'Support_Case'

Prevents firing for Internal_Case or other record types. Keeps flows focused.

Best Practice 6: Guard Against Infinite Recursion

If your flow updates a field on the triggering record, the update re-triggers the flow. Entry criteria can guard:

AND(
  /* real condition */,
  NOT(ISCHANGED([Record].Automation_Ran__c))
)

The flow sets Automation_Ran__c as part of its work; subsequent updates with Automation_Ran__c changed skip the flow. Recursion stops.

Before-save flows have lighter recursion issues since they don’t re-trigger record-triggered flows on the same save. After-save flows are where this matters.

Common Mistakes

Leaving criteria blank. “Always run” — every update triggers the flow, including irrelevant ones. Worst case: a user edits a description field and an unrelated automation fires 200 elements of work.

Redundant criteria. “Status = ‘Open’ OR Status = ‘Pending’ OR Status != ‘Closed’” — the first two are redundant if the third captures them. Simplify.

Checking for change without ISCHANGED. Field == 'New Value' fires every save where the field ends up as that value, not just when it changed to that value. Use ISCHANGED for transition detection.

Relying on runtime decisions. “We’ll check in the flow” — but by that point, you’ve already invested in firing. Push checks to entry criteria where they’re free.

Performance Impact at Scale

For an object with 1M records and a bulk API update touching all of them:

  • No entry criteria: flow fires 1M times. Even a fast flow (100ms per invocation) = 28 hours of flow work.
  • Criteria matching 1% of records: flow fires 10,000 times. 17 minutes of flow work.

A 100x difference. Entry criteria matter.

Testing Criteria

Test both positive and negative cases.

  • Create records that should fire the flow → verify they do.
  • Create records that shouldn’t fire → verify the flow doesn’t invoke.

The easiest way: flow run history. Check which records the flow invocation captured; ensure the list matches your intent.

Combining With Flow Tests

Flow Tests (covered elsewhere) can assert both firing and not-firing scenarios. Build your test set to include:

  • A record that matches criteria → flow runs, assertions pass.
  • A record that doesn’t match → flow should not fire; test that no side effects occurred.

Frequently Asked Questions

Do entry criteria apply to scheduled paths?

The scheduled path inherits the trigger criteria. If the record no longer meets criteria when the scheduled path fires, the path skips.

Are entry criteria metadata?

Yes — part of the flow’s metadata. Deploys and versions with the flow.

Can entry criteria reference related records’ fields?

Yes — dot-notation works for the full available schema on the triggering record. Account.Parent.Name is accessible.

What about formula vs. condition logic?

Formula gives more expressiveness. Condition logic is easier to read. Default to condition logic; switch to formula when you need something the builder can’t express.

Share