On-flow-exit entry vs event entry: hand-off from finished trip vs fresh behavior signal

On-flow-exit entry enrolls when a prior flow trip ends (optionally filtered by exit stage); event entry enrolls when a product/app event fires—chain journeys vs react to live behavior.

What is the difference between on-flow-exit entry and event entry?

After onboarding finishes, the team wants upsell. Two common wires: “when flow A ends, start B” versus “when Feature Used fires, start B.” The first is a stage hand-off; the second is a fresh behavior reaction.

On-flow-exit entry listens for trip-complete on the source flow — optionally filtered by exit stage/reason (goal hit, cancel, expire). Event entry listens to the product domain: purchase, view, click, install.

Programmer language: on-flow-exit = subscribe to flow A’s trip-complete as enrollment for B; event entry = subscribe to a domain event. If identity merge can race, add a short delay after exit. This complements journey vs campaign: one-shot campaigns do not hand off cleanly; chained journeys do.

How each works

On-flow-exit

Welcome ends → advanced feature activation starts. Filter to successful exits only, not unsubscribes. Use when the next stage depends on completing the prior contract, not a new click.

Risk: changing A’s exits silently floods or starves B. Treat exit contracts like an API.

Event entry

Same upsell starts on PowerFeature Clicked. People who never finished onboarding may enter unless you filter. Use when value signals come from product behavior, not from the onboarding calendar.

Comparison table

Suggested sequence

1. Write when the stage is “done.”
2. If done == the value signal → on-flow-exit.
3. If value is a separate behavior → event entry (+ “completed prior stage” filter if needed).
4. Delay 1–30 minutes after exit when identity/segments lag.
5. Set re-entry and entry caps on B separately.
6. Wiki a tiny diagram: A exits → B; event X → B in parallel.

Examples

SaaS: successful welcome exit → paid-feature education. Parallel: Limit Hit can open the same flow earlier for power users.

Ecommerce: welcome exit → favorite-category flow — or Category Viewed for browsers who skipped welcome, closer to journey vs realtime event campaign.

Win-back: often better as inactivity segment/event than chaining off an ancient flow exit — see re-engagement vs winback.

Leadara mapping

• Journeys: chain A→B via on-flow-exit, or keep B event-native.
• Events: trip-complete (if emitted) plus domain events.
• Segments: “finished stage” when raw exit hooks are missing.
• Email/SMS: change tone on hand-off; replaying onboarding copy into upsell fatigues people.

Common mistakes

• Chaining every flow because the canvas looks pretty.
• Not filtering exit reason (success vs unsubscribe).
• Ignoring people who show value via events before finishing A.
• Parallel exit+event paths double-messaging without priority caps.

One-line takeaway

On-flow-exit passes the baton after the finish line; event entry starts on a fresh signal. Write the stage contract before you wire.

Next step

Find one pair of flows that “should be sequential.” Decide whether the real signal is completion or behavior — enroll on that; filter the rest.

FAQ

If I duplicate flow A, does B break?

If B points at the old flow id, yes. Version the dependency.

Can I use both exit and event?

Yes — in parallel with entry caps so people are not double-messaged.

Should failed exits hand off too?

Sometimes to a recovery flow — not usually to the same upsell.

Is delay after exit required?

When identity merge or segment freshness lags, yes.

Is this journey orchestration?

Operationally related; this article is only about enrollment type.

Win-back — which entry?

Usually inactivity segment/event, not an old flow’s exit.

SMS on hand-off?

Only if the new stage has clear value; otherwise softer email.

Deep dive: treat exits like a versioned API

Product refactors A and adds three new exit reasons. B suddenly triples intake because it listened to “any exit.” Explicitly subscribe to exit_reason = completed and regression-test it. If your stack does not emit trip-complete, build a segment proxy — do not pretend you have on-flow-exit.

Iran vignette

Edtech app: 7-day welcome. On successful completion, “recommended course” flow starts (on-flow-exit filtered to completed). In parallel, Lesson Completed opens the same recommendations for people who skipped welcome, with has-not welcome_completed. Two doors, one content path, one-entry cap.

Priority when two entry doors open

If both on-flow-exit and an event feed journey B, write priority before go-live: first-entry wins with cooldown, event beats exit because it is a stronger value signal, or two content variants tagged by entry_source. Without a policy, people get two similar messages in a day. Log entry_source so you know which door performs.

Versioning and regression

Whenever A changes, regression-test B: successful exit, unsubscribe exit, expire exit, and the parallel event. Keep at least one staging profile per branch.

Hand-off copy

B’s first message should not re-welcome completers. Assume prior context and state the next step. For event entrants who skipped welcome, add a short alignment branch — three lines, not the whole series again.

Quick decision matrix for PMs

Pin the matrix. Half of endless enrollment debates collapse into one row.

Hidden cost of over-chaining

Every on-flow-exit link is an ops dependency. If you have more than two hand-offs in a row, you may have over-coded lifecycle into the canvas. A stage segment (stage = onboarded) with filter enrollment is often stabler than a three-flow chain. Ask: if we delete A tomorrow, how many paths die? If more than one, simplify.

Related reading

• Marketing journey vs campaign: multi-step path vs one send
• Journey vs realtime event campaign
• Re-engagement vs winback campaign