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

Shopify Plus flows — the workflows a Plus team builds in Shopify Flow, Shopify’s native automation app — are how ops teams stop doing by hand what a trigger-condition-action rule can do instead: holding a suspicious order, alerting purchasing before a SKU sells out, tagging a top customer, or routing a wholesale order into its own queue. This guide sets up four of those workflows with real setting values, then covers the failure mode that quietly breaks most of them: nobody notices when a flow stops running.

What are “Shopify Plus flows,” and what are you actually building?

“Shopify Plus flows” is the common shorthand for the automated workflows built inside Shopify Flow — the term describes what you’re building, not a separate product. Flow itself is the automation app; each individual automation inside it is a flow, or workflow, and every one has the same three parts: a trigger that starts it, one or more conditions that filter it, and one or more actions that run once the conditions pass.

That structure matters more than the name. An operator asking “how do I set up Shopify Plus flows” is really asking how to build trigger-condition-action rules for specific operational problems — fraud review, low stock, VIP customers, B2B orders — and that’s the shape this guide follows.

Which Shopify plans include Flow, and which specific triggers or actions are restricted to Shopify Plus, has changed over time and is not something to take from memory or from any single article, including this one. Check it directly: open Shopify Flow from your admin, start a new workflow, and look at what the trigger and action pickers actually offer your account, or check Shopify’s current Flow documentation and pricing pages. Building around a plan assumption that turns out to be wrong is a wasted setup session.

What do you need before you build a Shopify Flow workflow?

Before opening the workflow builder, you need three things decided, because Flow will ask for all three and a half-decided answer produces a half-working workflow.

The trigger event. Name the exact moment the workflow should start — not “when an order comes in” broadly, but “when an order is created” versus “when an order is paid” versus “when an order’s risk is assessed.” These are different points in the order lifecycle and Flow treats them as different triggers.

The filter logic. Decide what makes an order, customer or product a match — a tag, a field value, a threshold — in terms specific enough to write as a condition, not a general sense of “risky-looking orders.”

The owner of the outcome. Every workflow that produces an alert needs a named person or channel receiving it, not a general inbox. A workflow that tags an order but notifies nobody just adds an invisible label; a workflow that emails “ops@” gets read when someone has time, which for a time-sensitive fraud hold is often too late.

With those three answered, the build itself is mechanical.

Choose the trigger

Every Shopify Flow workflow starts with exactly one trigger — the single event Flow watches for. Common triggers for operational workflows include order created, order paid, inventory quantity changed, customer created and order tagged; the full, current list is in Flow’s own trigger picker, since Shopify adds and occasionally restructures triggers.

Pick the trigger that matches the earliest point you can act correctly, not the point that’s easiest to reason about. A fraud-hold workflow triggered on “order created” can act before capture; one triggered later, after fulfilment has already started, is closing the barn door. A low-stock workflow triggered on “inventory quantity changed” catches every adjustment, including manual recounts — which is usually what you want, since a recount revealing low stock is exactly as urgent as a sale doing it.

Add conditions to filter the trigger

A trigger without a condition fires on every matching event, which is rarely what an operational workflow should do. Conditions are the filter: a field comparison (quantity available is less than a number), a tag check (customer has tag “wholesale”), or a risk field (order’s risk level is high), combined with AND/OR logic when a workflow needs more than one thing to be true.

The setting most teams get wrong here is comparing the wrong version of a field. Shopify order risk, for example, can come from more than one source depending on your payment gateway and fraud tooling — check exactly which risk field and which value set (“low/medium/high” versus a numeric score) your condition is reading against, in the condition picker itself, rather than assuming it matches whatever your payment provider’s dashboard shows. A condition built against the wrong field passes or fails silently; it doesn’t throw an error, it just never matches the orders you meant it to catch.

Choose the actions

Actions are what happens once the conditions pass, and Flow runs them in the order you place them in the builder — first action first, second action second. Common actions for operational workflows: add a tag (to the order, customer or product), send an internal email, send a Slack message through Flow’s Slack connector, add a note to the order, or add a customer to a segment.

Chain actions deliberately. A fraud-hold workflow commonly needs two actions in sequence: tag the order (so it’s visible and filterable in the order list) and notify the fraud-review owner (so a person actually looks at it) — tagging alone creates a label nobody sees, and notifying alone creates an alert with nothing to filter on afterward if the person is out.

Name the workflow and turn it on

Name the workflow by its condition and its action, not just its trigger — “Order created” tells the next person nothing; “High-risk order → tag and notify fraud review” tells them what it does without opening it. This matters more as the workflow list grows past a handful, which happens quickly once fraud, stock, VIP and B2B workflows are all live.

Turn the workflow on only after testing it against a real or deliberately-triggering order, and leave workflows you’re not ready to run in draft rather than half-configuring them live — a workflow with an incomplete action list still fires on its trigger and condition, it just does less than you intended, which is a quieter failure than an error.

How do you build a fraud-hold workflow?

Trigger: order created. Condition: the order’s risk level, from your payment gateway’s or Shopify’s fraud analysis, is high — confirm the exact field name and value set in your condition picker before building on it, since this varies by gateway. Actions: add the tag fraud-hold, then send an internal notification (email or Slack) to the named fraud-review owner.

Hold, don’t cancel, by default. Tag and notify, then let a person decide whether to release or cancel the order — an automated cancellation on a false positive costs a real customer and a real sale, and risk scoring is a signal, not a verdict. Reserve a fully automatic cancel path, if you build one at all, for the narrowest, clearest-signal cases, and review those periodically to confirm the signal is still reliable.

How do you build a low-stock alert workflow?

Trigger: inventory quantity changed. Condition: quantity available for the SKU falls below a threshold you set. There’s no universal threshold number — metric to confirm for your own catalogue — set it to your typical reorder lead time multiplied by your average daily sell-through for that SKU, so the alert fires with enough runway to actually reorder. Actions: send an internal notification to purchasing or the buyer responsible for that SKU, and optionally tag the product low-stock so it’s filterable in the product list.

Trigger on quantity changed rather than a scheduled daily check. A scheduled check misses the SKU that sells through in an afternoon flash sale and doesn’t cross the threshold again until the next scheduled run finds it already gone.

How do you build a VIP-tagging workflow?

Trigger: order paid, so the workflow runs on every completed purchase rather than a batch job. Condition: the customer’s lifetime order count or total spent crosses your VIP threshold. Action: add the tag VIP to the customer, and optionally add the customer to a segment used elsewhere — in Klaviyo flows or in a separate Shopify Flow workflow that changes shipping or support handling for tagged customers.

This workflow tags a customer the same day they cross the threshold, because it runs on every paid order rather than on a schedule — which matters if a downstream workflow (a VIP shipping upgrade, a support routing rule) depends on that tag being current.

How do you build a B2B order-routing workflow?

Trigger: order created. Condition: the order or the customer carries a wholesale or B2B tag — set when the account is created, or matched against a customer field if you run B2B accounts through Shopify’s B2B tooling. Actions: add a routing tag (b2b-route) and notify the team or queue that handles wholesale fulfilment separately from direct-to-consumer orders.

Whether Flow can assign the actual fulfillment location automatically, rather than just tagging the order for a person to route, depends on which location-assignment actions your Flow account currently exposes — check the action picker rather than assuming a location-routing action exists, since this is one of the areas where Flow’s action list has changed over time. Where it doesn’t, tag-and-notify into a dedicated queue is the reliable fallback, and it’s what most B2B operations run on regardless.

What is the step most teams get wrong?

The step most teams get wrong is treating a live Shopify Flow workflow as finished once it’s turned on, with no plan for finding out when it silently stops running.

Shopify Flow does not push a failure alert to a person by default. When a workflow errors — a connected app disconnects the action it provided, a condition references a tag value that got renamed, a Slack authorization expires — that run shows as errored in the workflow’s run history, and nothing surfaces it beyond that history page unless someone opens it. A fraud-hold workflow that quietly stopped tagging orders two weeks ago looks, from the order list, exactly like a store with no fraud problem.

The fix is mechanical: assign a named person to check each operational workflow’s run history on a set cadence — weekly is reasonable for most $3M–$30M order volumes — and treat a rising error count the same way you’d treat a rising exception count anywhere else in ops: as the signal to fix the workflow, not to add more manual review around it. This is the same discipline that keeps an order-routing exception taxonomy honest; a workflow with no owner checking its output is a workflow nobody can trust.

How do you verify a Shopify Flow workflow actually works?

Verify a new workflow with a real or deliberately-triggering test before relying on it. For a fraud-hold workflow, place a test order structured to hit your risk condition (check your payment gateway’s test-mode risk simulation options, since forcing a genuinely high-risk score on a live account isn’t always straightforward) and confirm the tag applies and the notification arrives. For a low-stock workflow, manually adjust a test SKU’s inventory below your threshold and confirm the alert fires. For VIP tagging, use a test customer whose order history you control and confirm the tag applies at the exact threshold, not one order early or late.

Re-run this test after any change to the trigger, condition or connected app — not only at initial setup. A workflow that stops firing after a payment gateway update or an app reinstall is a common failure mode, and the run-history check from the previous section is what catches it if the deliberate re-test doesn’t happen first.

Who should not build workflows this way?

A brand running a handful of orders a day, with no fraud-review team, no wholesale channel and no SKU at real risk of stocking out unnoticed, doesn’t need four operational Shopify Flow workflows — a person checking the order list once a day is proportionate at that volume, and building automation nobody monitors is worse than no automation at all. This setup earns its complexity once order volume, SKU count or channel mix make a person catching every fraud-risk order, low-stock SKU or B2B order by eye impractical, which for most brands lines up with crossing into the $3M–$30M range and running Shopify Plus or a comparable paid platform.

Building and maintaining Shopify Flow workflows that stay reliable — with real condition values, named owners, and a monitoring habit instead of a “set it and forget it” assumption — is ops automation work: rules that either run themselves correctly or surface their own failure, not rules that quietly stop and wait for a customer complaint to reveal it. Pointerflow’s ops automation work builds and maintains exactly this for Shopify Plus and enterprise-subscription brands, and it’s built for the operating reality of scaling brands where the manual version has stopped working. For the platform-cost side of this decision, see what Shopify Plus actually costs; for the order-lifecycle workflows Flow often sits inside, see ecommerce order management.