Automating a Store with Shopify Flow

Running an online store looks like a thousand small decisions, and most of them are not decisions at all. They are reactions. An order over 500 dollars arrives, so you flag it for review. A customer buys their fifth time, so you tag them a VIP. Stock drops below ten units, so you tell someone to reorder. A payment looks odd, so you hold the fulfilment.

Notice the shape. Every one of those is the same sentence: when X happens, if Y is true, do Z. That is not judgment, it is a rule you are executing by hand, over and over, and doing it manually means it happens late, inconsistently, or not at all when you are busy.

The useful reframe is this: a store is an event stream. Orders created, customers registered, products added, inventory changed, refunds issued, payments captured. Automation is simply attaching rules to that stream.

This cursus covers the three ways Shopify lets you do that, and they are genuinely different tools rather than three flavours of the same thing:

• Flow (this lesson): react to events with no code.
• Functions (Lesson 2): change what the platform does during checkout, in code.
• APIs, webhooks, and apps (Lesson 3): build anything else, and choose between all of them.

Start with Flow, because it covers most of what merchants actually need, and because its limits are what motivate the other two.

Shopify Flow is a visual automation builder, and its entire model is three parts. Learn these and you know Flow.

• Trigger. The event that starts the workflow: an order is created, a customer is deleted, a product is added, inventory changes. Flow offers over 100 triggers, and the event-based ones fire immediately when something happens in the store.
• Condition. A filter deciding whether to continue. "Is the order total over 100?" "Is this customer tagged wholesale?" If the condition fails, the workflow stops there.
• Action. What Flow actually does: tag a customer, send an email, add an order note, call another app.

That is the whole grammar: when [trigger], if [condition], then [action].

What makes this powerful is not sophistication, it is coverage. The model is simple, but the trigger list spans the store, so a large share of daily operations fits the pattern without exception. The limitation is the flip side: Flow is reactive. It responds to things that have already happened. It cannot change what the platform does while something is happening, which is exactly the gap Lesson 2 fills.

One practical note: Flow began as a Shopify Plus feature and is now available on all plans except Starter. Enterprise-grade automation stopped being an enterprise-only tool, which is why it is the right first stop for almost any merchant.

The model is abstract until you see it. Three workflows that most stores can use immediately.

1. Catch high-risk orders before they ship

Trigger:    Order created
Condition:  Order total > $500
            AND shipping country != billing country
Action:     Add order tag "review"
            Hold fulfilment
            Send internal email to ops

This is fraud triage. It runs at 3am on a Sunday, which is exactly when a human would not.

2. Recognize your best customers automatically

Trigger:    Order paid
Condition:  Customer order count >= 5
Action:     Add customer tag "VIP"
            Send a thank-you email

The tag is the interesting part. Tags are how Flow writes state back into the store, and other systems then read it. Your email tool can segment on "VIP" without knowing anything about Flow.

3. Never quietly run out of stock

Trigger:    Inventory quantity changed
Condition:  Available < 10 AND product is active
Action:     Send Slack alert to purchasing
            Add product tag "reorder"

Notice what these have in common. None replaces a human's judgment. Each routes a situation to the right place at the right moment, which is the work humans do badly because it requires constant, boring vigilance. The purchasing manager still decides what to reorder. Flow just guarantees they find out.

The workflows above kept using tags, and that deserves a step of its own, because tags are how automation in Shopify composes.

A tag is just a label on an order, customer, or product. What makes it powerful is that it is shared, persistent state that everything can read. Flow writes a tag; your theme, your email platform, your reporting, your apps, and other Flow workflows can all act on it. Nothing needs to know Flow exists.

That turns tags into a decoupling layer, and the pattern generalizes:

• One workflow classifies, another acts. A workflow decides who is a VIP and tags them. A separate workflow, or app, gives VIPs free shipping. Change the definition of VIP in one place and everything downstream follows.
• Tags make automation visible. A human looking at an order sees "review" and understands why it is held. Compare that to logic hidden inside an app, which is invisible until it misbehaves.
• Tags survive. They persist on the record, so they are queryable and reportable later.

The caution is the natural one: tags are unstructured strings with no schema, so a store accumulates "VIP", "vip", and "V.I.P." until nothing matches. Treat your tag vocabulary as a real design decision, not an afterthought. For genuinely structured data, Shopify offers metafields, custom typed fields on records, which is the right tool when you need a value rather than a label.

The broader lesson: good automation is not one clever workflow. It is small pieces that communicate through shared state.

Flow's building experience changed with the Winter 2026 update, which integrated Shopify's Sidekick AI. Rather than assembling a workflow step by step from menus, a merchant can describe what they want in plain English and have the assistant construct it.

This is worth understanding for what it does and does not change.

What it changes: the authoring barrier. The hardest part of Flow was never the concept, "when X, if Y, do Z" is intuitive. It was discovery: knowing that a suitable trigger exists among more than a hundred, finding the right condition field, and wiring them correctly. Describing the intent skips the search entirely, which is a real reduction in friction and is why it matters most for the merchants who were never going to browse a trigger list.

What it does not change: the model. The generated workflow is still triggers, conditions, and actions. It still only reacts to events, and it still cannot do what Flow structurally cannot do. The assistant makes the tool easier to reach, not more capable.

What it adds: a review duty. A workflow you described but did not build is one you have not verified. It runs unattended, on real orders and real money, so the merchant's job shifts from construction to checking that the thing built matches what they meant. An automation that silently tags the wrong orders is worse than no automation, because you trust it.

The pattern generalizes well beyond Shopify: lowering the cost of building automation raises the importance of reviewing it.

Knowing a tool's limits is more valuable than knowing its features, and Flow has clear ones. Each is a signpost to the rest of the cursus.

• Flow is reactive, not participatory. It runs after an event. It cannot sit inside checkout and change the discount being calculated, the shipping options being offered, or whether the cart is allowed to proceed. Those decisions happen during the transaction, and Flow is not invited. That is Lesson 2, Functions.
• Flow works on Shopify's events and fields. If you need logic over data Shopify does not model, or an integration with a system Flow has no action for, you need code. That is Lesson 3, APIs and apps.
• Flow is not for bulk work. It reacts one event at a time. "Update 40,000 product prices" is not a trigger, it is a batch job. That is Lesson 3, bulk operations.
• Flow's logic is deliberately simple. Conditions and actions, not loops, complex state, or elaborate branching. This is a feature, it keeps workflows legible, but complicated logic does not fit.

The honest guidance for a merchant: start with Flow and stay there as long as you can. No code, no deployment, no app to maintain, and visible logic anyone on the team can read. Most store automation genuinely fits.

Reach past it only when you hit an actual wall, and notice which wall you hit, because it tells you exactly where to go. Needing to change checkout behaviour points to Functions. Needing external data or bulk changes points to the API. The next two lessons take those in turn.

A store event fires a trigger, Flow evaluates a condition and stops if it fails, and otherwise runs actions such as tagging records, sending notifications, or calling apps; tags written back become shared state other systems and workflows read.