Shopify Flow: automations on Basic, Grow and Advanced

Postazione e-commerce con un flusso di automazione visualizzato su laptop, simbolo di Shopify Flow

Shopify Flow is designed to automate repetitive, deterministic processes without turning every operational need into a custom app. The model is straightforward: an event starts the workflow, one or more conditions decide the path, and actions execute what you defined. The useful question is not “how many automations can I build?” but which processes are clear, observable, and reversible enough to deserve a workflow.

As of September 18, 2026, Shopify Flow is a free app available on Basic, Grow, and Advanced. Most features are shared across plans, but there are meaningful differences: for example, the Send HTTP Request action is available on Grow and Advanced, not Basic. Flow usage limits also depend on the API limits associated with the plan.

What Shopify Flow actually is

A Flow workflow is built from three elements: triggers, conditions, and actions. The trigger is the event that starts the workflow; conditions evaluate the available data; actions change data, send notifications, or start another step. This model works best when the rule can be expressed clearly: “when X happens, if Y and Z are true, then do A.”

That makes Flow different from an AI system interpreting an open-ended context. Flow is most useful when you want predictable behavior. If an order meets specific conditions, you can tag it; if a situation needs attention, you can send a notification; if a scheduled check finds matching records, you can process them in a loop.

For the broader picture, I cover the AI layer separately in this guide to AI and automation on Shopify. Flow does not replace that layer: it is mainly a deterministic automation tool.

Basic, Grow, and Advanced: what really changes

The first useful distinction is between automations that stay inside Shopify and integrations that need to communicate with external systems.

On Basic, you can use Shopify Flow and build workflows with triggers, conditions, and many native actions. What you do not get is Send HTTP Request. On Grow and Advanced, that action can be used to send requests to an external endpoint. Shopify also states that Flow has different usage limits according to the API limits of each plan.

This does not mean Grow or Advanced are required for automation. It means the plan becomes a technical constraint when a workflow must leave Shopify and communicate directly with an external service over HTTP.

First rule: automate a process, not an idea

A reliable workflow starts from a process that is already defined. Before opening Flow, write the rule in one sentence: what starts the process, which data matters, which exceptions exist, and what final result should be produced?

If the rule cannot be described clearly, the problem is not ready for Flow. Automating an ambiguous process only moves that ambiguity into a system that can then operate consistently but consistently wrong.

When I design an automation, I start from four questions:

what event should start the process;
which conditions must be true before taking action;
which action is actually necessary;
how the result will be checked after execution.

Five cases where Flow makes sense

1. Operational tags for orders and customers

Tags are useful when they classify cases that will later be filtered, reviewed, or handled by another process. A simple example is adding an order tag when a precise set of conditions is met, or segmenting a customer using information already available in the workflow.

The rule is to avoid decorative tags. If a tag does not feed a view, procedure, automation, or control, it is only adding noise.

2. Scheduled checks on orders

With a scheduled trigger and Get data actions, you can build periodic checks. Shopify documents workflows that retrieve orders left unfulfilled for a defined period, add a tag, or send a summary. Get data actions can return up to 100 resources at a time, so volume matters when the workflow is designed.

3. Internal notifications when someone really needs to act

Flow is useful for turning an operational condition into a signal. The goal is not to send more email; it is to notify someone only when an event requires a human decision. If every order produces an alert, the automation has simply moved noise from Shopify to the inbox.

4. Admin API actions that do not have a standard Flow block

The Send Admin API request action can use many GraphQL Admin API mutations even when the operation is not available as a dedicated Flow action. It is powerful, but it has explicit limits: it works with mutations, not queries, and not every mutation is supported.

This needs more discipline than a standard action. An API change can have a wider effect, so inputs, IDs, and conditions should be tightly controlled.

5. HTTP integrations with external services

On Grow and Advanced, Send HTTP Request can call an external URL. Shopify documents a maximum 30-second wait for the HTTP response; if no response arrives, the connection is closed and the request can be retried later.

If the goal is to change Shopify data through the GraphQL Admin API, Shopify recommends Send Admin API request instead. The distinction matters: HTTP is for connecting Flow to an external service; the Admin API action is for Shopify operations.

Testing before activation is not optional

Flow lets you test a workflow before activating it. Tests can use recorded events, real store data, or simulated events; Shopify can also generate test events with Sidekick.

The key point is that a test does not perform actions that modify live store data. When the workflow reaches the first action that would make a change, the test stops. For actions that connect to external services, Flow can show the configuration but cannot simulate the real response from that service.

Testing is therefore useful for checking logic, variables, conditions, and the path taken through the workflow. It does not replace a controlled check of real behavior after activation.

After activation: inspect runs, not just the diagram

A workflow can look correct in the editor and still encounter unexpected data, temporary errors, or execution limits. Shopify records workflow runs as execution logs and keeps them for 14 days, so you can inspect what happened at each step.

After fixing the cause of a failed run, Flow also supports manual retries. A retry uses the original trigger data but can fetch fresh data through Get data actions and re-run conditions and actions against the current state. It is not necessarily a frozen replay of the original execution.

Flow also provides the Workflow error occurred trigger, which can be used to build dedicated error notifications. For workflows that affect real operations, an error channel is more valuable than another “smart” automation.

Rate limits, timeouts, and idempotency

Shopify notes that Flow can intentionally rate-limit execution when one or more workflows consume too many resources. That can create delays and, in some cases, timeout errors.

This is why a workflow should be designed with repetition in mind. If the same action runs twice, could it create a duplicate, send something twice, or leave the store in an inconsistent state? If so, add an idempotency check: a tag, metafield, verifiable state, or condition that prevents the same operation from being applied twice.

This becomes even more important when Flow calls external systems. A retry should not automatically become a duplicate operation.

When Flow is not enough

Flow works well when the process is event-driven, deterministic, and relatively local. It becomes the wrong layer when you need complex application state, advanced external authentication, queues, long-running processing, a dedicated database, multi-store logic, or a purpose-built merchant interface.

In those cases, an embedded Shopify app or dedicated backend can be cleaner and easier to control. Likewise, if the logic must affect checkout behavior or commerce functions supported directly by the platform, the problem may belong to Shopify Functions and custom app development, not an increasingly complex Flow workflow.

The right decision is not “Flow or app” in absolute terms. Use Flow while the problem is truly a workflow; move to code when you are trying to make a workflow behave like an application.

Flow is not a reason to remove every app

A good automation can replace small redundant utilities, but app count alone is not a useful decision criterion. If an app provides a stable function, maintains integrations, offers a dedicated UX, or handles complexity that Flow should not absorb, removing it can make the system worse.

If you are cleaning up the stack, the better approach is the one I describe in this guide to Shopify app costs, performance, and replacement: first understand the problem each component solves, then decide whether to keep, replace, or remove it.

The criterion I use

For me, Flow is a good fit when I can describe the process with a verifiable rule, observe the result, and identify an error quickly. When a workflow starts accumulating exceptions, external calls, dependencies, and state, I no longer consider it “simple” just because the interface is visual.

The value of Flow is not avoiding code at all costs. It is keeping genuinely simple processes simple with a native, readable tool. When the problem crosses that boundary, changing architecture early is better than allowing the automation to become the store’s next fragile point.