Skip to main content
A variable condition branches a flow on one variable: the store’s plan, its revenue, a value the trigger carried, one of your custom fields. It’s the finer-grained sibling of the segment condition.

​
Configuring it

Three parts: the variable, the comparison, and, for most comparisons, a value. Comparison is case-insensitive and ignores surrounding spaces, so Pro matches pro . The panel summarises the wiring in a sentence (runs take the Yes branch when the variable matches, the No branch otherwise), so there’s no guessing which handle is which.

​
Which variables you can pick

The picker offers up to three groups:
  • Store variables, available on every trigger, resolved from the store the flow is running for.
  • Trigger variables, carried by the event itself: subscription_plan, charge_name, event_quantity and the rest.
  • Event properties, on the two triggers with a metered event behind them, Custom event is tracked and Usage view crosses a threshold: the properties your app sends with the event.
A trigger variable only exists on the triggers that carry it. Variables the current trigger doesn’t provide are shown as not available rather than hidden, and choosing one blocks activation with “a condition uses a variable this trigger does not provide”, because at runtime it would resolve to empty and the branch would be meaningless.

​
Event properties

When the trigger names one event, the picker lists the properties that event’s recent rows actually carried, each with the share of them holding it: total_price · on 100% of recent events, e.g. 512.5. It’s a sample of your history, so it tells you up front what a skip counter would otherwise tell you afterwards. On Custom event is tracked that is the custom event the trigger watches. On Usage view crosses a threshold it is the event the chosen view reads, since a view is defined over exactly one event key. Pick neither and the picker has nothing to sample, so you type the property instead. It is a sample, not a rule. Use another property… takes any property path you type, which is the case that matters when the release you’re shipping starts sending something your history has never held. Nothing about the sample gates saving or activation. An event property has no declared type: its shape is yours, and the same property can arrive as a number in one release and a word in the next. So every comparison is offered, and the one you pick is what says how the value is read: A value the comparison can’t read never matches: is greater than 500 against "expensive" takes the No branch rather than erring. And a bound the comparison can’t read is refused at activation: you can’t activate a flow comparing a number against a word. Contact variables can’t be used here. Conditions are evaluated before a recipient is known, so a per-recipient value has nothing to resolve against; they exist in the email editor only.

​
Empty values

A variable the trigger didn’t carry resolves to an empty string, which is exactly what is empty tests. That’s the honest way to branch on “did this event carry a plan name at all” instead of comparing against a blank string. This is how a missing event property behaves too, and it’s deliberate: an absent properties.total_price is never treated as 0. The condition takes the No branch, negative comparisons included. Silence is not disagreement.

​
Deleted variables

Custom fields join the variable catalog as custom_field_<handle>. Delete the field and the condition references a variable that no longer exists, so the builder flags it and blocks activation.
Last modified on September 17, 2026