Klaviyo Back in Stock Flow: Setup and Common Mistakes

If you have ever restocked twelve units of a product with four hundred people on the waitlist, sent the notification to all four hundred, and watched the product sell out in ninety seconds while three hundred and eighty people got an email pointing at a sold-out page, you already know what a Klaviyo back in stock flow gets wrong when nobody designs the send policy on purpose. The form and the trigger are the easy parts. The part that actually protects the customer relationship — deciding who gets told when a restock only covers a fraction of the waitlist — is the part most Shopify teams skip.

This guide covers the mechanics for building a klaviyo back in stock flow on Shopify: the on-site subscribe form, the trigger and its inventory threshold, variant-level versus product-level tracking, and the send-to-a-portion logic that keeps a small restock from becoming a mass disappointment.

What does a Klaviyo back in stock flow actually need?

A working back in stock setup has four parts: a form that captures interest at the variant a shopper actually wanted, a trigger that fires reliably off your Shopify inventory data, a threshold that decides what counts as “restocked,” and a send policy that limits the notification to what the new inventory can actually fulfil. Most guides stop after the first two. The last two are where restocks go wrong in practice.

None of these parts work in isolation. A form that captures product-level interest feeds a trigger that cannot distinguish sizes; a trigger with no threshold fires on a single returned unit; a send policy with no quantity check notifies everyone regardless of how much stock actually came back. Building all four together is what makes the flow behave the way an operator expects rather than the way the default template behaves.

How do you set up the on-site subscribe form?

Place the notify-me form directly on the product page, positioned where the add-to-cart button would normally sit, so it appears automatically when the viewed variant’s inventory drops to or below your out-of-stock threshold. Klaviyo’s own back in stock feature, and most third-party alternatives built for Shopify, render this as a native form rather than a pop-up, which matters because a pop-up interrupts a shopper who is actively trying to buy something else on the same page.

The setting that determines everything downstream is what the form actually submits: the product ID, or the specific variant ID the shopper had selected when the form appeared. If your theme’s product page does not pass the selected variant into the form by default — some don’t, particularly on older or heavily customised themes — the form will capture “interested in this product” when the shopper meant “interested in this in a medium.” That mismatch is invisible until the first mixed-size restock, when everyone on the product-level list gets notified about a size that isn’t theirs.

Check this before building anything else: open a product with multiple variants, submit the form on an out-of-stock variant, and confirm in Klaviyo which identifier landed on the profile. If it’s the parent product, fix the form’s variant binding first — the setting name for this varies by theme and by which back in stock app is doing the capturing, so confirm the exact field in your theme’s product template and your app’s own setup documentation before you build the flow on top of it.

What triggers the flow, and what threshold should fire it?

The trigger is a metric, not a webhook you write yourself: Klaviyo’s native back in stock feature and most Shopify inventory-sync apps emit an event — commonly named something close to “Back in Stock” or “Subscribed to Back in Stock” for the subscribe action, and a separate restock event or metric update for the notification trigger — when a tracked variant’s inventory moves from at-or-below-threshold to above it. Confirm the exact metric name your integration uses in your own Klaviyo account before building the flow, since naming differs between Klaviyo’s built-in feature and third-party back in stock apps, and has changed at least once as Klaviyo’s own feature set has matured.

The threshold question has two parts, and teams usually only think about one of them.

The subscribe threshold — the inventory count below which the notify-me form appears instead of add-to-cart — is usually set at zero, but some catalogues set it higher, showing the form once inventory drops to a handful of units so shoppers can join the waitlist before the item fully sells out. There’s no universally correct setting; it depends on how fast your best sellers move.

The fire threshold — the inventory count that counts as “restocked” and triggers the flow — is the one teams get wrong by leaving it at the default. If your system fires the instant inventory moves from zero to one, a single returned or cancelled-order unit will trigger a notification to your entire waitlist for a product you don’t meaningfully have back in stock. Set the fire threshold at a quantity that reflects an actual restock for that product, not any positive number, and treat this as a per-catalogue decision rather than a global default — a product that restocks in cases of five hundred behaves differently from a made-to-order item that restocks one unit at a time.

Variant-level or product-level: which should you track?

Track at the variant level whenever your product has meaningful variant differences — size, colour, material — because a shopper who wanted a medium does not want to be told a small is back. Product-level tracking is only appropriate for products with a single meaningful SKU, or where you’ve deliberately decided that any variant coming back is relevant news to everyone who signed up.

The trade-off is operational complexity. Variant-level tracking means your flow’s trigger filters, your segment definitions, and your form’s data capture all need to reference the specific variant, which is more setup work and more that can silently break — a filter written against the product ID when the data now lives on the variant will simply never match. Product-level tracking is simpler to build and more prone to sending irrelevant notifications.

A middle path some Shopify teams use: track at variant level for core sizing categories (apparel, footwear) and at product level for catalogues where variants are cosmetic (a single scent in two bottle sizes, say). Decide this per product type before you build the flow, not per flow — mixing the two approaches inside one flow’s logic is where filters start contradicting each other.

How do you handle a restock that doesn’t cover the waitlist?

Sending to the whole waitlist regardless of restock size is the step most teams get wrong, and it’s the reason back in stock flows generate as many complaints as they prevent. The default behaviour of most back in stock automation — Klaviyo’s native feature included, out of the box — is to notify the entire subscribed list the moment the fire threshold is crossed, with no check against how much inventory actually came back. A twelve-unit restock against a four-hundred-person waitlist produces the same email to all four hundred people that a four-hundred-unit restock would.

The fix is a comparison step between the trigger and the send: before the email branch runs, check the restocked quantity against the number of profiles waiting on that variant. Klaviyo doesn’t expose this as a single built-in setting — building it means either a flow filter referencing a property your inventory sync writes at restock time (restocked quantity), split against a conditional that compares it to the waiting list’s size, or a manual review step for high-waitlist products where an operator confirms the notification before it sends. Which approach fits depends on your order volume and how much manual oversight your team can sustain; a brand pushing dozens of restocks a week needs the filter automated, while a brand with a handful of high-demand drops can afford a person checking each one.

Whichever mechanism you use, decide what happens to the shoppers who don’t get notified in a given restock. The two honest options: hold them in the waiting segment so the next restock reconsiders them, or move them into a lower-priority queue that gets notified after the first wave has had a chance to purchase, with a defined delay before the second wave goes out. What you should not do is silently drop them — a shopper who signed up for a notification, didn’t get one, and later discovers the item sold out again without them ever hearing from you has a worse experience than if they’d never subscribed. This is the difference between a flow that manages a waitlist and a flow that just fires a mass email disguised as one.

How do you suppress and re-subscribe correctly?

After a notification sends, remove the notified subscribers from the active waiting-list metric or segment for that variant, otherwise a second small restock a week later re-triggers a notification to people who already received one, watched it sell out, and are now getting told again. Klaviyo’s native feature generally handles this suppression automatically once someone has been through the flow, but a custom-built version needs an explicit suppression step — either removing the person from the triggering list, or adding a flow filter that excludes anyone with a “notified” timestamp inside a recent window.

The portion of the waitlist held back from a partial notification is the opposite case: they should remain eligible, because they didn’t receive anything the first time. If your suppression logic doesn’t distinguish “was notified” from “was on the list when it fired,” you’ll end up suppressing people who never actually got the email — the same failure mode covered in more general terms in Klaviyo not syncing Shopify orders, where a flow’s filter references the wrong property and silently drops profiles that should have qualified.

How do you verify the flow worked?

Don’t trust a back in stock flow until you’ve watched it handle a real restock with a waitlist larger than the restocked quantity. Pick a variant with a modest number of subscribers, restock a quantity below that subscriber count, and check three things afterward: who actually received the email, whether the product link in that email routes to the correct variant rather than the parent product’s default variant, and whether the un-notified portion of the list is still active for the next restock rather than having been suppressed by mistake.

Testing with a full restock — quantity comfortably above the waitlist size — only proves the trigger and the form work. It doesn’t touch the part of the flow that decides who gets left out, which is the part that was never tested in most of the “working” back in stock flows that go on to disappoint a waitlist six months later.

Frequently asked questions

Back in stock is a narrow flow, but it sits inside the same lifecycle programme as every other automated send a brand runs — welcome, abandoned cart, post-purchase, win-back — and it’s usually the flow that reveals whether a brand’s lifecycle flows programme was built with real settings and real send logic, or copied from a template and left alone. A restock notification that goes to the wrong four hundred people is a small technical miss with an outsized effect on how those four hundred people feel about being on your list at all. For a brand in the $3M–$30M range running enough SKUs to have real restock volume, this is exactly the kind of flow worth auditing on its own, not assuming it’s fine because it exists — a question worth asking directly if you’re scaling past the point where a template flow quietly stops matching how your catalogue actually restocks.