Skip to main content
A segment condition branches a flow on whether the triggering store belongs to a segment. It’s how one automation serves your whole base while treating slices of it differently.

​
Configuring it

Pick a segment and whether the Yes branch means is in or is not in it. The panel shows how many stores currently match, so you can sanity-check the segment before wiring the branches. Every condition has two outgoing branches, Yes and No, and you connect each to whatever should happen. A branch you leave empty simply ends the flow for stores that take it, but a condition has to lead somewhere on at least one branch, or the flow won’t activate.

​
How membership is decided

Segment membership is computed when the flow runs, not when you built it. A segment is a set of rules, never a stored list, so the store is evaluated against those rules at that moment: a store that qualified yesterday and doesn’t today takes the No branch today.

​
Conditions run before any action

Every condition in a flow is evaluated before the first action runs. That’s deliberate: a transient failure while evaluating can’t leave a run half-sent, with one email out and the next step never reached.

​
Deleted segments

If the segment is deleted after you wire it in, the builder marks the condition and blocks activation until you pick another one. It doesn’t quietly treat everyone as a match.
Segments are a CRM feature, so the condition needs segment access to configure. If you can’t see segments, the picker says so instead of offering an empty list.
Last modified on August 21, 2026