Klaviyo Flows: A Step-by-Step Setup for Shopify Teams

A Klaviyo flow is an automated sequence of messages that a customer’s own behaviour switches on — placing an order, abandoning a cart, signing up, going quiet — and then routes, branches and paces without anyone pressing send. Most of what goes wrong with Klaviyo flows for ecommerce has nothing to do with the copy inside them: it is a trigger split doing the job of a conditional split, a flow filter that only checks once, or two flows with a legitimate claim on the same moment both winning it.

The rest of this guide covers what each mechanism actually does, the core set of Klaviyo flows a Shopify brand needs, the order to build them in, and the failure mode that shows up as a customer getting the same discount code twice in one week.

What settings does a Klaviyo flow need before you build it?

Three things need to be true before a flow is worth building, and skipping any of them is where most “the flow isn’t sending” tickets originate.

The trigger event has to fire the way you think it does. If you are building on Shopify’s Placed Order metric, confirm it in Klaviyo’s own metrics view against a real order before you build anything downstream of it — not by trusting that the integration is connected, but by finding the event. If Klaviyo is not receiving Shopify orders at all, that is a separate, prior problem: the diagnostic ladder for Klaviyo not syncing Shopify orders works through connection status, backfill windows, and the metric-choice mistakes that look identical to a sync failure but are not one.

The properties your filters will depend on have to exist on every path that creates the trigger event. A storefront checkout and a subscription-platform renewal can both produce a Placed Order event while carrying different properties. A flow filter written and tested only against storefront orders will pass storefront customers and silently exclude everyone else, and the flow will look healthy the entire time.

Segmentation has to already exist for anything that isn’t a raw event. Flows that branch on “is a VIP” or “has purchased category X twice” depend on a segment or a list being correct before the flow ever runs — a flow cannot fix a segment definition that is wrong upstream.

How does a trigger split decide who enters a flow?

A trigger split is the first fork in the road, and it runs exactly once: the instant a profile enters the flow. It evaluates a property or an attribute of the triggering event itself — order value above a line, a specific product category, a UTM source, acquisition segment — and sends that profile down one branch or another for the rest of the flow.

The thing to remember about a trigger split is that it never re-checks. If a profile enters the high-value branch because their cart was large, and they later remove items and check out for less, the trigger split does not notice — it made its decision at the door. That makes it the right tool for anything genuinely fixed at the moment of entry, and the wrong tool for anything that changes as the flow runs, which is what a conditional split is for.

How does a conditional split branch people inside a flow?

A conditional split sits further into the flow, after at least one message and usually after a time delay, and it re-evaluates its condition at that later point rather than at entry. Did they open the first email? Click a specific link? Place an order since entering the flow? The answer to each of those can only be known after time has passed, which is exactly why a conditional split — not a trigger split — is the mechanism for behaviour-based branching.

The practical pattern in an abandoned-checkout flow: message one goes to everyone who abandoned, then a conditional split checks whether they have since placed an order. Anyone who has exits the flow or moves to a short thank-you branch; anyone who has not continues to message two. Skipping this check is how a brand ends up reminding a customer to buy something they already bought, which reads as either careless or slightly unsettling depending on how close together the two messages land.

How do time delays and smart sending control when a message actually sends?

A time delay is a flow-level instruction — wait a number of hours, wait a number of days, the exact figure being a decision you make per message — and it belongs to that one flow alone. Smart sending is different in kind: it is an account-level (or, depending on configuration, list-level) rule that suppresses a marketing send to a profile that already received a marketing message inside a set window, and it applies across every flow and campaign at once, not just the one you are currently editing.

That distinction is the source of a specific confusion. A flow’s time delay finishing correctly does not guarantee the message sends — smart sending can still hold it back because a different flow, or a campaign, reached that same profile first. Check your account’s smart sending window in Settings before assuming a flow is broken when its messages show as skipped rather than delivered; the window itself is an account configuration value, not a fixed number, and it is worth confirming what yours is currently set to before diagnosing anything downstream of it.

Flow filters are the third lever, and they can sit anywhere in a flow, not only at the top. A filter placed immediately after the trigger checks once, the same way a trigger split does. A filter placed after a time delay, further into the flow, re-checks its condition at that later point — the same filter in two different positions in the same flow produces two different populations, which is a common source of a flow that “worked in testing” and then behaves differently once it has been live for a week.

What is the core set of Klaviyo flows for a Shopify brand, and what order should you build them in?

Build in the order a customer actually meets the brand, because building out of order means testing a later flow’s overlap logic against an earlier trigger that does not exist yet.

1. Welcome. Fires on list sign-up. Introduces the brand and, where a discount is offered, is the flow every later flow needs to check against — a subject its own build guide covers in full, but the setting worth naming here is that welcome is almost always the flow other flows have to filter around, not the other way round.
2. Abandoned checkout. Fires on Checkout Started without a matching Placed Order inside a set window. The mechanics of this specific flow — the exact conditional split checking for a completed order, the message spacing, the discount-or-no-discount decision — are covered in the abandoned cart guide; build it second because it is the flow most likely to overlap with welcome for a brand new subscriber who abandons within the first hour.
3. Post-purchase. Fires on Placed Order or Fulfilled Order. Confirmation, shipping updates where not handled transactionally, a review request, and the first cross-sell touch. Renewal orders and storefront orders often need separate branches inside this flow, because a subscription platform’s order does not always carry the same properties a storefront checkout does.
4. Back-in-stock. Fires on a restock event tied to a specific product a customer asked to be notified about. Narrow in scope, but worth building fourth because it is the first flow in the set that can legitimately fire for someone who is also mid-flow in post-purchase or an offer campaign — the overlap this article’s next section is about.
5. Win-back or sunset. Fires on inactivity past a defined threshold. The flow that decides whether a quiet profile gets one more attempt or gets suppressed from future sends; its own build guide covers the mechanics of the inactivity window and the suppression decision in full.

Those five flows are the working set. Everything past them — a browse-abandonment flow, a replenishment flow, a VIP-tier flow — is refinement layered onto a base that already covers the moments where the largest, most predictable revenue sits, and each addition increases the number of flows a new build has to be checked against.

Why does one customer get the same offer twice — and how do flow filters stop it?

Double-messaging is the failure mode any of these five flows can produce, and it is the step almost every Shopify team skips.

Each flow, built and tested on its own, is correct. Welcome sends its discount correctly. Abandoned checkout sends its own discount correctly. Tested independently, both pass. The failure only appears at the account level: take a hypothetical new subscriber who abandons a cart minutes after signing up — both flows have a legitimate trigger, so both fire, and the customer receives two different discount codes in one afternoon from a brand that looks, from the outside, like it does not know what it already sent.

Klaviyo has no built-in concept of “this profile is already receiving a discount from a different flow right now.” That coordination has to be built by the person building the flow, using the mechanisms already covered:

• A flow filter checking flow membership. Before abandoned checkout sends its discount message, add a filter checking whether the profile is still inside the welcome flow, and hold or skip the discount step if they are.
• Smart sending categories, where your plan supports them, so a discount-bearing message in one flow counts against the smart sending window the same way a discount-bearing message in another flow does — the two flows do not need to know about each other directly if they both respect the same suppression window.
• A single source of truth for “has an active discount code,” usually a custom property set when any flow issues one and checked by every other flow before it issues its own.

This kind of collision is not discoverable by testing a single flow in isolation, because a single flow, tested alone, has no other flow to collide with. It only shows up once the flow goes live inside an account that already has other flows running — which is exactly why the check has to happen before launch, against the account as it actually is, not against the flow as it was built.

How do you verify a new flow actually works?

Open the flow’s analytics tab after launch and read the skipped count and its reasons, not only the delivered count — a flow with zero errors and a high skip rate is not broken, it is being correctly suppressed, and the reason tells you by what.

Common skip reasons and what each one means: smart sending held the message because another send reached that profile first; a flow filter excluded the profile at the point it was checked; the profile is suppressed — bounced, complained, or unsubscribed; or the specific message inside the flow is set to manual review rather than live, which is a common leftover from testing that never gets switched back.

Watch this for the first week rather than the first day. A two-flow overlap often does not appear on day one — it needs a normal week of sign-ups, abandonments and purchases happening in whatever order real customers actually produce them before two flows both find a reason to fire for the same person.

One naming note worth clearing up before it causes a search miss: Shopify Flow is a separate automation tool built into Shopify itself, for store-side workflows like fraud holds and inventory tagging, and it has no connection to Klaviyo flows beyond the shared word. If the workflow you actually need is inside Shopify’s admin rather than Klaviyo’s, the Shopify Plus flows build guide covers that tool instead.

Getting the mechanism right — the right split for the right decision, filters that check where they need to, and a launch that accounts for every other live flow — is what turns a set of automations into a coordinated program instead of five scripts that happen to run in the same account. That coordination, tuned to the specific overlaps a given product catalogue and purchase cycle create, is the core of what a lifecycle flows engagement builds and then maintains as new flows get added. It matters most for brands past the point where a handful of default flows covers the business — the scaling-brands stage, where enough flows are live simultaneously that a coordination gap between two of them is no longer a rare accident but a weekly occurrence.