Exit mark immediate vs delay-step complete: flagged now, fully gone when the wait ends

An exit exception marks the user to leave as soon as the event fires, but if they are sitting in a delay/wait step they stay until that timer ends—then they leave without advancing to later steps.

What is the difference between an immediate exit mark and leaving when a delay step completes?

Support opens a ticket: “They bought on day 1 of a 5-day wait—why are they still in the journey?” The answer is usually not a bug. Many orchestration engines mark exit immediately when the exception event fires, yet fully remove the person from later steps only after the current delay finishes.

Think of it as a mutex: exit_flag = true now; the wait timer still runs; on timer end, if the flag is set, skip every downstream node.

How the timeline actually works

So “still in the journey” during the wait is often expected. What must not happen is sending the post-wait nurture SMS after purchase.

This pairs with exit on conversion vs global exit criteria: conversion exits and property ejects both need a clear story for delay occupants.

Concrete examples

Ecommerce quiet period after purchase

Journey: browse abandon → wait 2 days → email → wait 3 days → SMS coupon. Exit exception: order_completed.

If they buy 6 hours after browse, they stay visually “in wait” until the 2-day timer ends, then drop—without the email or SMS. Your analytics should count them as exited-on-conversion, not as email-skipped for another reason.

SaaS trial with billing delay

Trial nurture has a 7-day wait before a sales SMS. Exit on subscription_started. A user who converts on day 2 must not get the day-7 sales SMS. Confirm the wait step respects the exit mark at completion.

Design rules

1. List every wait/delay longer than a few hours and name the exit events that should kill later sends.
2. Prefer short waits when exit events are frequent (cart → purchase).
3. Do not schedule irreversible side effects (unique voucher burn, webhook charge) only on “exited during wait” without a guard.
4. Align CRM and MA reports: “in delay + exit marked” ≠ “engaged with next message”.
5. Document whether exit during a message-send step cancels the in-flight send (vendor-specific; test it).

Leadara mapping (events, segments, journeys, email/SMS)

• Events: define clear exit events (order_completed, subscription_started, unsubscribe).
• Journeys: attach exit criteria / conversion goals; audit every wait step for post-exit leakage.
• Segments: optional suppression segment “purchased in last X days” as a belt-and-suspenders filter on later email/SMS steps.
• Email / SMS: never rely on “they should have exited” without a filter if the creative would be embarrassing after conversion.

Also skim Skipped for profile filter vs journey exit: still scheduled vs left the path so entry gates and exit marks are not copy-pasted from each other.

Common mistakes

• Treating “still in journey during wait” as a platform defect.
• Long waits without conversion exits on purchase/subscribe.
• Counting delay-time as message engagement.
• Exit only on email click, forgetting SMS-only converters.
• No QA path: buy during wait, prove later steps are skipped.

One-line takeaway

Exit mark is immediate; physical leave from a delay is at timer end—later steps must not run.

Next step

Pick your longest live wait. Force a conversion event mid-wait on a test profile. Confirm zero downstream email/SMS and that reporting labels the exit correctly.

FAQ

Why do I still see them in the journey UI after purchase?

They are likely still finishing the active delay while marked to exit.

Do they receive the message that was already sending?

Depends on the engine. Test in-flight sends explicitly.

Is this the same as a goal step?

Related but not identical—goals often record conversion; exit marks control membership. See wait vs goal automation posts for the measurement angle.

Should every journey use immediate hard-kick from delays?

Only if your vendor supports aborting delays. Otherwise design for mark-then-complete semantics.

What about quiet hours waits?

Same rule: exit mark should prevent the post-quiet-hours promotional send after conversion.

Can segments replace exit marks?

Segments help as filters; they are slower/less precise than event exits for mid-wait purchases.

Double-counting in funnel reports?

Decide whether “exited during delay” counts as converted-in-journey or converted-outside; document one definition.

Step-by-step troubleshooting

1. Reproduce with a test profile and a 10-minute wait.
2. Fire the exit event at minute 2.
3. Watch membership until minute 10.
4. Assert no later nodes executed.
5. Export events for analytics and label the pattern.

Versus global exit criteria alone

Global exits that watch profile properties may lag behind a real-time purchase event. Prefer event exits for money moments; use property exits for slower state like “became employee”.

Metrics to watch

• Downstream send rate after conversion (target ≈ 0)
• Median time from exit event to full leave
• Support tickets “got discount after I bought”
• Holdout-adjusted revenue for journeys with long waits

Product + data note

Ticket line: exit=order_completed mark_immediate; waits complete then drop; assert no SMS after purchase.

Programmer framing

on exit_event:
  trip.exit_marked = true
on delay_complete:
  if trip.exit_marked: leave(trip); do_not_run(downstream)
  else: continue(next_node)

Guards: never schedule coupon SMS after order_completed; add a segment filter on later steps as belt-and-suspenders; test in-flight sends.

Acceptance tests

1. 10-minute wait; exit at minute 2; assert leave at minute 10 with zero downstream sends.
2. Exit while idle between steps; assert immediate leave.
3. Exit during an email send; document whether the in-flight message still delivers.
4. Analytics: label “exit during delay” distinctly from “filter skip”.

Support macro

“They may still appear in the journey until the active wait ends, but they are marked to exit and will not receive later emails/SMS.” Put that sentence in the helpdesk.

Related design choice: wait vs goal

If you only need to measure conversion, a goal step may be enough. If you need to stop messaging, you need an exit mark (and delay-complete semantics). Do not confuse the two in the ticket.

Iran ecommerce vignette

A Tehran fashion brand runs browse → wait 48h → SMS 10% off. Customers who buy on the app within the first evening still show as “in journey” the next morning. Support thinks automation is broken. After you explain mark-vs-complete, they stop force-removing profiles and instead watch downstream send = 0. Refunds from “discount after I already paid” drop in a week.

When you should abort waits aggressively

• High-price SKUs where a post-purchase coupon destroys margin
• Regulated messages (finance, health) where speaking after conversion is non-compliant
• Journeys that burn unique voucher codes on later steps

If your stack cannot abort a delay early, shorten waits and add hard filters on every later email/SMS node.

Collaboration with data

Export a daily table: profile_id, exit_event_at, delay_ends_at, downstream_send_count. Anything with downstream_send_count > 0 after a purchase exit is an incident.

Decision tree for authors

1. Is the user in a delay/wait right now? If no → expect immediate leave on exit event.
2. If yes → expect leave at delay end; assert downstream count = 0.
3. Is the creative harmful after conversion? If yes → add step-level filters even with exits.
4. Does finance need same-day suppression in BI? If yes → join on exit_event_at, not on leave_at.

Copy bank for FAQ schema

• Q: Why still in journey after purchase during a wait?
• A: Marked to exit immediately; fully removed when the active delay completes; later steps do not run.

## Related reading

• Skipped for profile filter vs journey exit: still scheduled vs left the path
• Exit on conversion vs global exit criteria: goal kill-switch vs property/behavior eject
• Wait until event vs fixed delay: pause for a signal vs pause for a clock

Related reading

• Exit on conversion vs global exit criteria: goal kill-switch vs property/behavior eject
• Skipped for profile filter vs journey exit: still scheduled vs left the path
• Wait until event vs fixed delay: pause for a signal vs pause for a clock