Not verified hands-on. This article was written from primary documentation rather than reproduced in an org, so it carries no tested-release badge. If you run it and something differs, say so in the comments and it gets tested and corrected.

Briefly: switch a record-triggered flow’s entry criteria to a formula when the condition builder cannot express what you need, which in practice means mixed AND and OR logic across different fields, a comparison between two fields on the same record, or the change-detection functions that only exist in this one place. Everything else belongs in the condition builder, because a formula in the Start element is invisible from the canvas and nobody reading the flow later will think to look inside it.

What the condition builder cannot do

The builder gives you rows of field, operator, value, joined by All Conditions, Any Condition, or custom logic like 1 AND (2 OR 3). Custom logic covers more than people assume, so try it first. What it genuinely cannot do:

  • Compare one field on the record to another field on the same record. The value side of a builder row does not accept $Record.
  • Compare a field to something computed, such as a date arithmetic expression or a substring.
  • Express a condition on a parent record’s field, since the builder only offers fields on the triggering object.
  • Use functions. Anything involving TEXT, ISBLANK on a mixed type, CONTAINS across a multi-select, or date maths needs a formula.

Choose Formula Evaluates to True in the Condition Requirements picklist and you get a single boolean expression instead of the rows.

The functions that only work here

This is the real reason to use the formula option. In the entry criteria of a record-triggered flow you can use ISCHANGED, PRIORVALUE and ISNEW, exactly as you would in a validation rule. In a formula resource inside the same flow, those functions do not exist.

AND(
  ISCHANGED({!$Record.StageName}),
  TEXT({!$Record.StageName}) = "Closed Won",
  {!$Record.Amount} > 50000
)

Without the formula option you would express the change part with the Is Changed operator in the builder, which works and is clearer for a single field. The formula earns its place when the change detection is one clause among several that need OR logic.

A cross-object example the builder cannot touch:

AND(
  ISPICKVAL({!$Record.Status}, "Escalated"),
  NOT(ISBLANK({!$Record.Account.Owner.Email})),
  {!$Record.CloseDate} < TODAY() + 30
)

The readability cost, and it is real

Condition builder rows render on the Start element in the canvas. You open a flow, glance at the top, and know when it fires. A formula shows as a note that criteria are defined by a formula, and the expression is three clicks away in a panel.

That matters more than it sounds. Entry criteria are the single most important thing about a record-triggered flow, and the most common question asked of any automation is “why did this run?” or “why did this not run?”. A formula makes that question slower to answer for every person who comes after you.

Two habits make it survivable:

  • Write the flow’s description field to say in plain English when it fires. The description is visible in Flow Trigger Explorer and in the flow list.
  • Format the formula across lines with indentation, as above. The editor keeps whitespace and it costs nothing.

The interaction with the update setting

Below the criteria sits the option controlling when the flow runs for updated records: every time the record is saved and meets the criteria, or only when the record is updated to meet the criteria, meaning it did not meet them before and now does.

That second option and ISCHANGED in a formula solve overlapping problems, and combining them carelessly filters out runs you wanted. If your formula already contains ISCHANGED on the deciding field, leave the setting on every time. If you rely on the setting, do not also test ISCHANGED on the same field.

The “only when updated to meet” option is also the cheapest recursion guard available. A flow that updates the record it triggered on will not re-enter if the record no longer newly meets the criteria.

Frequently asked

Can I use a formula resource from the flow in the entry criteria? No. The entry criteria formula is written inline in the Start element and cannot reference formula resources defined elsewhere in the flow.

Does the formula work in a before-save flow? Yes, and ISCHANGED works there too, even though $Record__Prior is unavailable inside the flow body.

Why does my ISCHANGED formula fire on insert? On insert there is no prior value, and the behaviour differs from what people expect. Add an explicit test on ISNEW() to make the intent visible either way.

Can I use entry criteria formulas on a scheduled flow? A schedule-triggered flow filters records with the condition builder on its Start element rather than this formula option, so complex filtering there usually means a Decision after the record is retrieved.