Automation Conditions and Branching

Condition steps, the nine operators, ALL/ANY matching, and routing by survey sentiment.

Conditions decide which path a workflow takes. There are two kinds, plus filtering on the trigger itself.

Condition steps

A Condition step tests a value and splits the flow into a true branch and a false branch. Each branch can run a completely different sequence, and neither has to rejoin.

Operators

Operator	Meaning
`EQUAL`	Equal to
`NOT_EQUAL`	Not equal to
`GREATER_THAN`	Greater than
`GREATER_THAN_OR_EQUAL`	Greater than or equal to
`LESS_THAN`	Less than
`LESS_THAN_OR_EQUAL`	Less than or equal to
`CONTAINS`	Contains any of the values as a substring
`CONTAINS_ALL`	Contains every value as a substring
`NOT_CONTAINS`	Contains none of the values

Which operators are offered depends on the field’s type — you won’t be shown GREATER_THAN for a boolean. Field types are string, integer, number, date, datetime, boolean and enum.

Watch the boundaries. LESS_THAN 3 excludes 3-star reviews. If you mean “3 and below”, use LESS_THAN_OR_EQUAL. This is the single most common condition mistake.

Trigger conditions

Model Event triggers can carry their own conditions, evaluated before the workflow runs at all. Filtering here rather than in a Condition step is usually better — nothing downstream starts, so nothing is wasted.

Pick the model you’re triggering on and the builder offers the fields that model supports, each with the operators valid for its type. Fields backed by a fixed set of values — an enum, or a link to another record — offer their options directly rather than making you type a value.

ALL vs ANY

Rules combine two ways:

ALL (AND) — every rule must match
ANY (OR) — any one rule matching is enough

Default to ALL. ANY is broader than people expect, and a broad trigger is how automations end up firing on things nobody intended.

Survey Response Condition

A special step that waits for a survey response, then routes on sentiment. Four branches:

positive
neutral
negative
default — the fallback, including when no response arrives

This is the cleanest way to build a recovery flow:

Send Survey
  ↓
Survey Response Condition
  ├─ positive  →  ask for a public review
  ├─ neutral   →  thank them, no further action
  ├─ negative  →  notify team, escalate to team inbox
  └─ default   →  wait, then send one reminder

Always configure the default branch. People don’t answer surveys. If the default does nothing, a meaningful share of customers silently fall out of the flow.

Conditions worth adding to almost everything

A rating or sentiment threshold. Without one, your “sorry to hear that” flow fires on five-star reviews.

A recency check. The most common complaint about automated systems isn’t the message — it’s the third message.

A touchpoint filter. So the front desk’s feedback reaches the front desk manager, and the spa’s reaches the spa.

An internal exclusion. Your own team will trigger workflows while testing. Exclude staff addresses.

Keep them simple

If a workflow needs more than about four conditions, it’s usually two workflows. Split it — two simple flows are far easier to debug, and much easier to explain to whoever inherits them.

Conditions and branching