Klaviyo Automation: Which Flows Earn a Place, and Why

What is Klaviyo automation, and which flows are worth building?

Klaviyo automation is a flow: a sequence of messages that triggers on customer behaviour, a list join, a segment entry, or a metric like a completed order, rather than a date on a send calendar. Once switched on, a flow keeps running in the background for as long as it stays live, reacting to every profile that meets its trigger, which is what separates it from a campaign a person schedules and sends once. Vendor-reported figures put a substantial share of total email revenue behind automated flows rather than campaigns, across a large enough sample of brands that the general pattern is worth taking seriously even without knowing your own exact split.

Not every flow that could be built is a flow worth building. A flow earns its place when it reacts to a behaviour that is both common enough to matter and specific enough to warrant a message tailored to it. A welcome series earns its place because nearly every subscriber passes through the moment it targets. An abandoned cart flow earns its place because cart abandonment is common and the intent signal, adding an item, is strong. A flow built around a narrow, rare behaviour, one that only a handful of profiles ever trigger in a typical month, usually costs more in ongoing review than it returns, and that cost only grows once you count it against every other flow it has to be checked against for overlap. This article is about which flows clear that bar and how they are sequenced against each other; the mechanics of getting a payload from Klaviyo to another system, a related but separate problem, are covered in more depth at /blog/klaviyo-webhooks.

Which lifecycle automations actually earn a place in your account?

A welcome series earns its place first, because it targets the single highest-attention moment a subscriber gives you, the minutes right after opting in, and because nearly every list has enough volume through this trigger to justify the build. Its job is to set expectations and start building purchase intent, not to sell aggressively in the first message; a series that opens with a hard discount push trains new subscribers to wait for one before they will engage with anything else.

An abandoned cart flow earns its place because it targets the strongest buying-intent signal available short of a completed order: someone added a specific item and stopped before paying. Browse abandonment, triggered by a product view without an add-to-cart, earns a place too, but as a weaker, lower-frequency message, because a view alone is a much noisier signal of intent than a cart add. Post-purchase flows earn their place by shaping what happens after the sale, delivery updates, a first-reorder nudge for consumable categories, a request for a review timed after the product has actually had time to be used, and they matter because the experience they cover is what every later winback flow either has to recover from or benefits from having gotten right the first time. A winback or lapsed-customer flow earns its place last in the build order, not because it matters less, but because its trigger, a gap since last order, only means something once you know what a normal repurchase gap looks like for your own catalogue, which the earlier flows help establish. A replenishment flow, tied to an average consumption cycle for a consumable product, and a VIP or loyalty-tier flow, tied to spend or order-count thresholds, round out the set for brands with the catalogue and volume to support them; a brand without a genuinely repeat-purchase consumable product has no real replenishment flow to build, whatever a template suggests.

What entry conditions should trigger each flow?

An entry condition is the specific trigger, and any filters attached to it, that decide who starts a flow and when. Answer the entry question narrowly: a welcome flow should trigger on list or segment join, not on every profile update, or you risk restarting the series for someone who was never really a new subscriber, just a profile whose record changed for an unrelated reason. An abandoned cart flow should trigger on the cart or checkout-started metric, with a filter that excludes anyone whose cart converted to an order within a short window after the trigger, since some checkouts complete faster than the flow’s own first send delay.

Filters matter as much as the trigger metric itself. A flow filter checked immediately after the trigger, before the first message sends, catches a profile who no longer qualifies by the time the flow actually starts, someone who unsubscribed in the gap between adding to cart and the first email firing, for instance. Set entry filters to match the exact condition that made the flow worth sending in the first place: an abandoned cart flow should generally exclude anyone who already has an open order for that exact cart, and a winback flow should exclude anyone who purchased again after the lapsed-customer segment calculation ran but before the flow itself triggered. Getting this narrow is what keeps a flow’s entry list matching the reality of who actually still needs the message, rather than a snapshot of who matched a condition minutes or hours earlier.

What exit conditions stop a flow before it wastes a send?

An exit condition removes a profile from a flow once the situation it exists to address has already resolved, most commonly because the profile converted. Every revenue-focused flow, abandoned cart, browse abandonment, winback, needs a conversion-based exit checked against a real order event, not just a time-based end to the sequence. Without one, a flow keeps pushing a message about a problem, an unpurchased cart, a lapsed relationship, that no longer exists, and a customer who already bought the item still gets an email nudging them to buy it, which reads as the brand not paying attention rather than as automation working well.

Exit conditions need a second category too: a subscription or consent-based exit, so a profile who unsubscribes or is suppressed for compliance reasons stops receiving every remaining step immediately, not just future flows. Build both categories into every flow from the start rather than retrofitting them once a customer complains, because the retrofit always happens after the damage, a customer annoyed by an email about a purchase they already made, has already occurred. A flow with a strong entry condition and no exit condition is not really automation, it is a scheduled sequence with a trigger attached, and the difference matters the moment customer behaviour changes mid-flow, which it does constantly at real volume.

How does one event end up qualifying a profile for more than one flow?

Two flows sharing a trigger metric is common, not a mistake by itself, and it happens naturally as a lifecycle programme grows: a product view can be the entry condition for browse abandonment and also feed a segment that a win-back-adjacent re-engagement flow watches. The problem is not the shared trigger; it is building each flow in isolation, without checking whether another live flow reacts to the same signal, which is exactly what happens when flows get added one at a time over months by whoever needed the next one.

The practical fix is a shared exclusion list, or an equivalent segment condition, checked at entry to every flow that could plausibly fire from an overlapping trigger. Before a browse abandonment flow sends, check whether the profile is already inside the abandoned cart flow for the same session; if they are, the stronger-intent flow should win and the weaker one should hold or exit. This requires treating your flow list as a set that has to be reviewed together periodically, not as a folder of independent builds, because a new flow added in isolation next quarter can reopen an overlap that a review would have caught before launch.

Which three failure modes let overlapping automations double-send?

A shared trigger with no exclusion between the flows it feeds causes the first failure. Two flows react to the same metric, each was built and tested on its own, and each looks correct in isolation, but a profile who matches both triggers within the same window gets both messages, because nothing in either flow checks whether the other one is also running for that profile. This is the most common of the three because it requires no misconfiguration, just two flows that were never reviewed against each other.

An exit check that lags behind the conversion it is meant to catch causes the second failure. A customer buys the exact item their abandoned cart flow is chasing, the flow’s exit condition is checked against a completed-order metric, and the check is correct, but it runs on the flow’s own evaluation schedule rather than instantly at the moment of purchase. If the next queued message in the flow is due to send before that evaluation catches up, it goes out anyway, congratulating no one on abandoning something they already bought. This looks identical to a missing exit condition from the customer’s side, but the fix is different: the exit logic exists, it is just not fast enough relative to the flow’s own send cadence.

A re-entry setting that lets a profile start a flow again while an earlier occurrence is still sitting in a time-delay step causes the third failure. This produces two live occurrences of one flow running on one person simultaneously, which is functionally different from two different flows overlapping, because it means the same message sequence is now doubled rather than two distinct messages colliding. It shows up most on flows with a broad, frequently repeated trigger, browse abandonment on a catalogue with high repeat browsing, where a profile can plausibly re-trigger the entry condition before the first run has finished its delay steps. Checking and tightening re-entry settings on high-frequency-trigger flows specifically, rather than applying one blanket setting across every flow, is what closes this one.

How do you sequence automations so they don’t compete for the same inbox minute?

Give every flow a priority relative to the others it could plausibly overlap with, and encode that priority as an exclusion rule rather than leaving it as a judgement call made differently by whoever built each flow. A strong-intent, time-sensitive flow, abandoned cart, should generally suppress a weaker, less time-sensitive one, browse abandonment or a general newsletter-style automation, for the same customer in the same window. Write this down somewhere a new flow builder will actually see it before they launch flow six or seven, because the rule only works if everyone building a new flow checks it against the existing list.

A global send-time or frequency setting, where your account offers one, is a coarser but useful backstop underneath the flow-level exclusion rules, catching combinations nobody thought to exclude explicitly. Treat it as a backstop, not a substitute for exclusion logic, because a frequency cap alone cannot decide which of two competing messages a customer should actually get; it can only decide how many total messages go out, sometimes suppressing the more relevant one and letting the less relevant one through depending on send order. The two mechanisms do different jobs: exclusion rules decide who should not be in a given flow at all, and a frequency setting decides how many messages someone gets across everything once all the flows they legitimately qualify for have already been narrowed down.

How do you test automation overlap before it ships?

Build a small set of test profiles specifically designed to qualify for more than one flow at once, the way a real customer eventually will, rather than testing each flow in isolation and assuming the combination will behave the way the individual pieces did separately. A profile that views a product, adds it to cart, then does not check out, should be walked through in a low-volume or non-production state to confirm which flow actually sends, in what order, and whether the excluded flow genuinely held back rather than firing anyway because a filter was scoped too narrowly.

Test the timing edge cases specifically, not just the happy path. Walk a profile through converting a few minutes after a flow’s first message has already sent but before the second is due, to confirm the exit condition catches it before the next send rather than after. Walk a second profile through re-triggering a high-frequency flow’s entry condition while an earlier occurrence is still mid-delay, to confirm the re-entry setting behaves the way you intend rather than the way it defaulted to when the flow was first built. These edge cases are cheap to test with a handful of seed profiles and expensive to discover for the first time from a customer complaint, so the small investment up front is worth it every time a new flow is added to an account that already has several running.

What does a missed exit condition actually look like on a live account?

It looks ordinary until it lands in one specific inbox. A customer abandons a cart on a Monday, the flow’s first message sends that evening, and the customer buys the item directly, through a different channel entirely, on Tuesday morning. The flow’s exit condition is configured correctly and checks against completed orders, but the check runs on its own schedule and has not yet caught up by the time the second message in the sequence is due. That message sends Tuesday afternoon, a few hours after the customer already has a shipping confirmation for the exact item the email is chasing them about.

Nothing in the flow is broken in the sense of throwing an error; every setting did what it was configured to do. What broke is the assumption that a checked exit condition and an instant exit condition are the same thing, and they are not, because the gap between an order completing and a flow’s evaluation catching up is exactly the kind of detail that only shows up once real customer timing collides with a flow’s own cadence. Checking flow analytics for messages sent to profiles who converted before the send is the way to catch this pattern after the fact; tightening the evaluation frequency, or adding a shorter delay before the second message specifically, is the way to reduce how often it happens.

When should a lifecycle automation be retired rather than tweaked?

Retire a flow once the behaviour it targets has stopped being distinct enough to deserve its own trigger and message, or once a newer flow has quietly absorbed the same audience with a better sequence. A browse abandonment flow built years ago, before a cart abandonment flow existed, might now be catching a subset of profiles the cart flow already handles better, in which case keeping both running is pure overlap risk with no upside. A flow targeting a segment that has shrunk to a size not worth the ongoing review, because the product line it was built around was discontinued, is a candidate for retirement even if nothing about it is technically broken.

Do not confuse “hasn’t been touched recently” with “needs retiring.” A stable, well-performing welcome series that nobody has edited in a long stretch has simply finished being built, not gone stale, and touching it for the sake of activity risks introducing the exact overlap or exit-condition regression this article has spent most of its length warning about. Review flows on a schedule tied to catalogue and customer-behaviour changes, a new product line, a new subscription option, a shift in typical repurchase timing, not on a schedule tied to how long it has been since someone last opened the flow builder.

What breaks as flow count grows, and how do you keep it from becoming unmanageable?

Past a certain number of live flows, the review burden stops growing linearly with flow count and starts growing with the number of pairs of flows that could plausibly overlap, which increases much faster. Ten flows means up to forty-five possible pairs to have thought about; add a few more and the number of pairs to reason about roughly doubles again, an illustrative way of putting a shape on a problem that in practice means overlap review time grows faster than the team adding flows usually expects. This is the practical ceiling on how many automations a lifecycle programme should run: not a fixed count, but the point where nobody can any longer hold the full overlap map in their head or in a document anyone actually checks before launching flow number twelve.

Keep the map current deliberately: a single document or dashboard listing every live flow, its trigger, its exit conditions, and which other flows it is explicitly excluded from or by. Update it as part of launching any new flow, not as a separate cleanup project scheduled for whenever there is spare time, because the moment it falls out of date is the moment the next overlap slips through unreviewed. A brand at $3M–$30M in revenue with a genuinely broad catalogue, several purchase patterns and a subscription option alongside one-off purchases, will reasonably end up with more flows than a narrower brand at the same revenue, and that is fine; what is not fine is more flows than anyone is actively tracking against each other. A flow-revenue calculator, such as the one at /tools/flow-revenue-calculator, is a reasonable way to sanity-check whether a proposed new flow’s likely contribution justifies the ongoing overlap-review cost before it gets built at all.

Getting the automation set right, the flows that earn their place, their entry and exit conditions, and the overlap rules between them, is squarely a lifecycle flows problem, and one that keeps changing shape as a catalogue, a subscription mix or a customer base grows. That ongoing work, reviewing the flow map as conditions change rather than setting it once and leaving it, is what /services/lifecycle-flows covers.