Flow is genuinely good — start there
Before anyone sells you a custom build, the honest position is this: Shopify Flow is the right answer more often than people who sell custom development like to admit. It is built into Shopify Plus, it requires no hosting, and for a large class of "when this happens, do that" rules it is the fastest, cheapest, most maintainable option available. If a merchant can express their need as a Flow, they almost always should.
Flow does a handful of things very well:
- Event-driven triggers on native Shopify events — order created, fulfilment created, customer created, inventory changed.
- Simple conditional logic — tag a customer over a spend threshold, flag a high-risk order, hold a fulfilment.
- Native actions — add tags, send internal emails, call other Shopify-aware apps that expose Flow connectors.
- Zero infrastructure — no servers, no deployments, no API version migrations to chase.
For straightforward operational rules, reaching for Shopify automation through Flow first is simply good engineering judgement. The question this article answers is the one that matters once you've outgrown it: where does Flow stop being enough, and what replaces it?
Where Flow quietly breaks down
Flow's limits are real, and they tend to reveal themselves gradually — a workflow that started clean accretes branches until it becomes unmaintainable, or a requirement appears that Flow simply can't express. The recurring walls are:
Branching complexity
A Flow with two or three conditions reads fine. A Flow with a dozen nested conditions, multiple action branches and special cases becomes a diagram nobody can safely change. There is no version control, no code review, no diff — just a visual tree that one person understands and everyone else is afraid to touch. Complex business logic wants to live in code, where it can be tested and reasoned about.
External systems
Flow lives inside Shopify's worldview. The moment your automation needs to talk to an ERP, a WMS, a 3PL, a custom database or any API that doesn't ship a Flow connector, you are at the edge of what Flow can do. You can sometimes bridge with an HTTP-request action or a middleware tool, but you've now added a dependency Flow can't monitor or retry properly. Connecting external systems reliably is the territory of Shopify ERP integration, not a visual rule engine — and what breaks in a Shopify ERP integration explains why.
Data transforms
Flow is good at deciding and poor at transforming. If your automation needs to reshape data — compute a derived value, reformat a SKU, aggregate line items, look up a mapping table, enrich an order with data from elsewhere — Flow either can't or forces you into awkward contortions. Real data manipulation belongs in code.
Rate limits and volume
Flow runs inside Shopify's platform limits. High-volume stores, bulk operations, or automations that fan out into many API calls can hit throttling, and Flow gives you little control over batching, backoff or queuing. Custom automation lets you manage throughput deliberately.
Observability
This is the quiet one. When a Flow fails or behaves unexpectedly, your visibility is limited. There's no real logging you control, no alerting you can wire to your on-call, no replay of a failed run against fixed inputs. For automations that move money or stock, "I think it's working" is not good enough — and Flow makes "I think" the best you can do.
The comparison, side by side
| Dimension | Shopify Flow | Custom / webhook-driven automation |
|---|---|---|
| Setup cost | Minimal, built into Plus | Build cost + hosting |
| Maintenance | No infra; logic in a visual tree | Code to own; API migrations |
| Branching logic | Fine when simple, fragile when deep | Testable, version-controlled |
| External systems | Limited; connector-dependent | Full control via APIs |
| Data transforms | Weak | Arbitrary |
| Volume / rate limits | Platform-bound, little control | Queues, batching, backoff |
| Observability | Limited visibility | Logging, alerting, replay |
| Best for | Simple native rules | Complex, integrated, high-stakes logic |
When to move from Flow to custom automation
You don't replace Flow because custom is "better" — you replace it when Flow stops being able to express what you need safely. Move to custom, webhook-driven automation when:
- The logic touches systems Shopify can't see. An ERP, a WMS, a 3PL, a custom database — anything that needs reliable retries and idempotency.
- The branching has outgrown comprehension. When changing a workflow feels risky because nobody is sure what it touches, the logic needs to be in code with tests.
- You need to transform, not just decide. Derived values, lookups, enrichment, reshaping.
- Failure is expensive. If a missed automation means a lost order, a wrong invoice or an oversell, you need logging, alerting and replay — observability Flow can't give you.
- Volume is fighting you. Throttling, bulk operations, or fan-out API calls that need deliberate queuing and backoff.
The replacement pattern is consistent: a verified webhook handler, a queue, idempotent processing, retries with backoff, and monitoring — the same backbone described in Shopify GraphQL, webhooks and dashboards explained. At that point you are building a small custom Shopify app, and the decision deserves the same scrutiny as any build — see when to replace Shopify plugins with a custom app for the parallel reasoning, and what to automate in a growing store for picking the right candidates.
A pragmatic hybrid is usually the answer
The cleanest setups rarely choose one or the other. They use Flow for the simple, native rules where it excels — tagging, internal notifications, basic holds — and reserve custom automation for the logic that is complex, integrated or high-stakes. Flow stays the fast path for the simple 80%; custom carries the 20% that actually carries risk. Trying to force everything into Flow produces unmaintainable trees; trying to build everything custom wastes money on rules Flow would have handled for free.
FAQ
Is Shopify Flow good enough for most stores?
For most simple operational rules, yes — and you should use it. Flow is fast, free on Plus, and maintainable for "when X happens, do Y" logic. You only outgrow it when the logic gets genuinely complex, needs external systems, or carries real financial risk.
When should I move from Flow to a custom app?
When Flow can't express your logic safely: it needs to talk to systems Shopify can't see, the branching has become too complex to change confidently, you need real data transforms, or failure is expensive enough to demand logging, alerting and replay.
Can Flow talk to my ERP?
Sometimes, through an HTTP-request action or middleware, but not reliably for anything financially material. Flow can't give you the retries, idempotency and reconciliation a real ERP integration needs. For that, webhook-driven custom automation is the right tool.
Does custom automation mean a big project?
Not necessarily. The pattern — verified webhook, queue, idempotent handler, retries, monitoring — can be a small, focused build for a single workflow. It's only large when the logic itself is large or touches many systems.
What's the biggest hidden cost of staying on Flow too long?
Observability. A Flow that fails silently for a high-stakes process can compound damage for days before anyone notices. The moment "I think it's working" isn't acceptable, you've outgrown Flow.
Can I use Flow and custom automation together?
Yes, and you usually should. Keep Flow for the simple native rules it handles well and reserve custom, webhook-driven automation for the complex, integrated or high-risk logic. The hybrid is almost always cheaper and more maintainable than going all-in on either.
Not sure which of your workflows belong in Flow and which need custom automation? A diagnosis answers that before you spend on a build. Book a paid Shopify audit and we'll map your automation candidates by complexity and risk — or start with a free Shopify audit to see where the quick wins are.