When Should an Automated Flow End? Exit Conditions Matter More Than Triggers.
The worst automation failure is not failing to fire. It is correctly executing a customer job that has become obsolete.
A shopper adds an item to cart, starts checkout, and purchases before the next reminder is due. The queued email still says the cart is waiting. The trigger, delay, and send node worked, yet the customer received the wrong message.
Entry explains why a customer qualified at one moment. A send-time gate asks whether the action is still valid now. A wait step moves work into the future; it does not freeze consent, reachability, order state, cart facts, or journey priority.
Four Changes Revoke the Old Job
- The job is complete: a purchase ends recovery for the relevant shopping episode; lifetime order history should not block a genuinely new episode.
- A deeper state owns the next step: Browse → Cart → Checkout → Purchase. Broader paths yield to deeper verified intent.
- The relationship boundary changed: unsubscribe, complaint, suppression, unreachable address, missing contact basis, competing journey, or contact pressure can block the action.
- Message facts expired: cart, inventory, price, delivery, offer, event freshness, or identity correlation no longer support the queued message.
Five Explicit Dispositions
- send — the current job, relationship boundary, and message facts remain valid.
- wait — authoritative state is still processing or too uncertain to judge safely.
- skip — this action should not run, but a later action may be evaluated again.
- exit — the old task has ended and no longer owns recovery.
- transition — another path may be relevant, subject to its own checks.
Lifecycle Handoff Needs Ownership
Within one correlated shopping episode, browse, cart, checkout, and purchase are not four additive permissions to contact the same person. The deepest currently valid state should own the next recovery action, and purchase should end recovery.

Klaviyo documents one platform-specific boundary: trigger filters are checked at entry, while profile filters are checked again before actionable elements; a failed profile filter may skip the current action without globally removing a profile from the Flow. Other platforms differ. Preserve the operating method, not the label: entry starts the path, current state authorizes the action.
Test the Stop
Create a test checkout, confirm entry, queue a recovery action, place an order before dispatch, and verify that the latest order state produces an inspectable skip or exit reason. Repeat for delayed events, missing identity links, out-of-order events, and a genuinely new shopping episode.

Nine Questions Before You Rewrite the Third Email
- What customer job is this path trying to complete?
- What event proves that job is complete?
- What deeper state owns the next action?
- Are consent, reachability, unsubscribe, complaint, and suppression still valid?
- Is another Campaign or Flow creating too much contact pressure?
- Are cart, inventory, price, delivery, and offer facts still accurate?
- When events are delayed, missing, out of order, or unlinked, should the system wait, skip, or recheck?
- Can the system retain the reason, rule version, decision time, and evidence time?
- How can a new shopping episode enter without being blocked by historical events?
Before changing copy, discount, cadence, or design, draw the stop line before every message. The expensive failure is a changed customer state followed by a perfectly executed obsolete task.