How do you stop browse, cart and checkout emails overlapping?

Stop abandonment emails overlapping by giving each stage a stop rule: product-view reminders yield to cart or checkout recovery, and purchase stops recovery messages. Check eligibility again before sending. Then test event arrival and other senders: a correct rule cannot act on a purchase the platform has not recorded yet.

A shopper can view a product, add it to their cart and start checkout during the same visit. Those actions can qualify them for different flows. Naming the flows differently does not make their audiences exclusive.

The useful question is what should happen to each pending message as that shopper moves on.

Map the handoff by event, not by flow name

Use this as a proposed policy for forward progress through a shopping journey. Confirm that the destination flow is active, receives the right events and can actually serve the shopper before excluding them from an earlier stage.

This follows the downstream exclusions in Klaviyo’s browse-flow setup and cart-flow setup. The browse guide makes the cart exclusion conditional on having a separate cart-triggered flow.

Read the trigger behind the label. Our browse abandonment explainer covers why that name can mean different stages, while the abandoned cart explainer separates cart additions from checkout starts.

Behavioural eligibility also does not establish permission to email someone. That is a separate sending decision.

Put stop rules where they are checked again

An entry check answers whether someone qualified when the flow began. It does not, by itself, answer whether a later message still fits.

In the documented metric-triggered implementation, trigger filters are checked at entry; profile filters are checked at entry and before actions. Use the latter for downstream behaviour that can change while someone waits.

For a concrete purchase safeguard, the documented path is:

Flow trigger → Profile Filters → Add a Flow Filter → What someone has done (or not done). Set Placed Order to zero occurrences since starting the flow, then save.

For the cart-triggered flow, add the corresponding zero-checkouts-since-entry condition. Join the checkout and purchase exclusions with AND. A shopper who started checkout but has not bought fails the checkout condition and passes the purchase condition. Using OR would let them through.

Keep the time window intentional. Excluding purchases since entry stops reminders for someone who just bought. Excluding anyone who has ever purchased would also remove returning customers with a new abandoned purchase.

There is another boundary: “since starting this flow” does not cover earlier events. If someone starts checkout and then triggers a new product-view flow, decide whether recent checkout activity should block that new entry. Define and test that history rule for your journey; do not turn it into an all-time ban.

Finally, distinguish a skipped message from permanent removal. In this implementation, someone who fails a profile filter before an action can still proceed to later steps, where eligibility is checked again.

Separate handoffs from frequency and entry blocking

These controls answer different questions:

• Stage eligibility: does this reminder still match the shopper’s progress?
• Re-entry frequency: can the same person enter this workflow again yet?
• Cross-workflow exclusion: should membership in another workflow block entry here?

Omnisend’s multiple-abandonment guide documents separate exit conditions, Skip Contacts rules and frequency settings. It also says there is no built-in workflow priority setting: with its described mutual suppression, the workflow entered first takes precedence.

That matters if your intended policy is for checkout recovery to take over from browsing. An entry-blocking rule is not proof that the handoff will happen. Test whether the later flow actually admits the shopper, including any exclusion for recently completed workflows.

Also distinguish a collision from successive messages. If the browse email went out before the shopper started checkout, a later checkout email does not prove that the browse stop rule failed. Whether those sends are too close together is a separate contact-frequency decision.

Trace the wrong send before changing the delay

Start with an affected message and its sender. The cart setup guide warns that default store-platform recovery emails can duplicate an external recovery flow. Check for a second recovery sender before editing the flow you assumed sent it. Keep purchase receipts outside this duplicate-recovery decision.

Next compare what happened with what the messaging platform knew at send time. The metric-flow troubleshooting guide identifies delayed purchase events as a cause of abandonment emails after purchase. Its investigation opens the affected profile’s purchase event and compares the timestamps in Activity Details.

An invented example shows the distinction:

At the message decision, the purchase has happened but its event is unavailable. The purchase safeguard cannot use it yet. This is an illustration, not a measured sync delay or a recommended send schedule.

Investigate the event feed and integration before treating a longer delay as the complete fix. Separately verify that the message has the purchase safeguard at all.

Test the paths and retain the result

Use the forward policy above as the expected result, then compare it with actual recipient activity. These are suggested acceptance checks, not tests we ran on a store.

For the invented timeline above, change purchase recording to before 11:00. Under the proposed rules, no abandonment message should remain eligible at that check. Compare that expected outcome with the late-event version rather than declaring both runs a filter failure.

Keep a record you can revisit:

Profile · sender/workflow/message · trigger · event time · recorded time · message decision/send time · filter and window · expected result · actual send or skip reason.

That record makes the repair specific: change a rule, repair event availability, remove a duplicate sender, or revise the intended handoff.

Can browse and cart abandonment flows run together?

Yes, but give the earlier stage downstream exclusions and verify the handoff. A shopper’s product view and cart addition can qualify them for separate flows; having both flows does not automatically make their messages exclusive.

Does a purchase automatically stop abandoned-cart emails?

Check the purchase exclusion and the event feed. In Klaviyo’s documented metric-triggered setup, a purchase-since-entry profile filter stops later messages when the purchase event is available to the platform. An event arriving after evaluation cannot stop that earlier send.

Should I exclude everyone who has bought before?

Use the window that matches the job. A purchase since this recovery flow began is different from a purchase at any time. An all-time exclusion would also remove returning customers shopping again.

Does receiving both a browse and checkout email prove the filters failed?

No. Compare message times with the checkout event and its availability. A browse message sent before checkout began can be followed by a checkout message without a failed downstream exclusion; decide their spacing separately.