What Shopify Flow Templates Actually Automate, and When You Need a Custom App Instead
Shopify Flow's template library covers order tagging, low-stock alerts, and risk flags out of the box, but its connector list covers a small slice of the App Store and it has no scheduled trigger — so most real automation needs run out of template road within a week. Before you build a custom app, there's a middle step almost every guide skips: the Send an HTTP request action, which reaches any endpoint you control without one. Here's where templates stop, where that action picks up, and where you actually hit the Plus-only wall for custom triggers.
Shopify Flow's template library — Tag orders over a value, Notify on high-risk orders, Restock alerts, and a few dozen others under Settings > Flow > Templates — covers the automations every store needs in the first week and almost nothing after that. Flow only talks natively to the apps that have built a Flow connector, which is a small fraction of everything listed in the App Store, and it has no time-based trigger at all: nothing runs "every day at 9am" or "three days after fulfillment" without a workaround. Once your automation needs an app Flow doesn't know, or a schedule instead of an event, the templates are done and you're choosing between three real options — not two, because most guides skip the middle one.
That middle option is Flow's Send an HTTP request action, and it's worth understanding before you scope a custom app, because it solves a large share of what people assume requires one.
What the template library actually covers
Flow's templates are pre-built workflows for the automations Shopify sees often enough to standardize: tagging orders by value or risk level, sending Slack or email alerts on stock thresholds, adding customers to a segment after N orders, auto-archiving products at zero inventory. Each template pairs one trigger (an event — order created, inventory quantity changed, customer created) with one or more actions (tag, notify, add to collection, run another workflow). You can clone a template and adjust its conditions in the visual editor without writing anything, which is genuinely most of what a small catalog needs.
The two structural limits that templates don't warn you about, and that we covered in more depth in our guide to Flow's trigger behavior, are that every workflow has exactly one trigger — no combining "order created OR order paid" into a single flow — and that Flow connectors only reach the roughly 300 apps that built one. If the app you need to react to or push data into isn't on that list, no template gets you there, cloned or not.
Where templates run out, concretely
Three requests show up constantly in Shopify's own community forums and none of them are solvable with a template:
- A scheduled run. "Every morning, check for orders unfulfilled after 48 hours" has no trigger, because Flow only fires on events, not clocks. The usual workaround is triggering off a low-frequency event you don't otherwise care about (a scheduled price sync, for instance) purely to get a periodic tick.
- An app with no Flow connector. If your 3PL, review platform, or ERP hasn't built a Flow integration, Flow has no native way to talk to it — tag it, query it, or send it data — regardless of what the app itself can technically do over an API.
- Logic that needs to branch on data Flow can't see. Flow's built-in conditions compare fields Shopify already exposes. A rule that depends on a computed value — loyalty tier from an external system, a fraud score from a risk vendor you haven't connected — has nothing for Flow's condition step to check against.
All three are solvable without a custom app, because Flow ships an action built for exactly this gap.
The escape hatch almost every guide skips: Send an HTTP request
Flow's Send an HTTP request action lets any workflow call a URL you control — GET, POST, PUT, DELETE, or HEAD — with your own headers and payload, and it will wait up to 30 seconds for a response. Since Shopify's 2026 update to the action, it also stores secrets like API tokens encrypted inside the workflow and returns the response body to later steps, where a Run code action can parse it with JSON.parse and hand the result back into the workflow's conditions and actions.
Practically, that means all three gaps above are solvable with a small serverless function (a Netlify or Cloudflare function is enough) that the HTTP request action calls: the function checks the clock and decides whether today's run should do anything, calls the app with no Flow connector on your behalf, or looks up the external data point and returns a computed value for Flow's next step to branch on. None of this requires Shopify Plus, an app listing, or the Dev Dashboard — it's available on every paid plan, because it's a built-in action, not a custom app extension. This is the option that gets skipped in almost every "Flow isn't enough, build a custom app" writeup, and it's the right stopping point for a large share of the requests that seem to demand one.
Where it stops being enough: the HTTP request action can call out and receive data back, but it can't originate a trigger — Flow still has to be started by something Shopify already fires an event for. If nothing in Shopify's own event list corresponds to what should kick off the workflow (an external system's own change, with nothing on the Shopify side to hang a trigger on), that's the actual line where you need a custom trigger, not just custom logic inside an existing one.
The wall almost nobody mentions: custom triggers are Plus-only
Shopify's own developer documentation for building Flow app extensions states it plainly, if you go looking for it: a custom app's Flow trigger and action extensions are available only to a Shopify Plus store that has that custom app installed. If you're not on Plus, you cannot register your own custom trigger or action inside Flow through a private, store-specific app — full stop. The only path to a genuinely custom Flow extension on a non-Plus store is publishing an app through the Shopify App Store, even as an unlisted, single-merchant app distributed by direct install link, which carries real review and maintenance overhead most single-store automation problems don't justify.
This is the detail that separates "Flow isn't enough, build a custom app" from something you can actually act on: for a non-Plus store, "build a custom app" doesn't mean what it sounds like. It doesn't buy you a custom Flow trigger. It buys you a piece of software that talks to Shopify's Admin API directly, runs on its own schedule or webhook, and does the job without going through Flow's UI at all — which, for most of what people reach for Flow to do, is a heavier build than the HTTP-request middle step above.
Building it after January 1, 2026: the Dev Dashboard change
If a genuine custom app is the right call — for logic too complex for Flow's branching, or work that needs to coordinate several systems with shared state — how you create one changed this year. Shopify's admin no longer has a "Create an app" flow for new custom apps; as of January 1, 2026, new custom apps must be built in the Dev Dashboard, Shopify's separate developer console, not the store admin. The shape of the work is: create the app in the Dev Dashboard, define its API scopes and URLs, release a version, then generate a custom-distribution install link tied to your specific store domain and install it from there. Existing custom apps created before the cutoff aren't affected, but any agency or in-house dev still pointing a client to the old admin-based "Develop apps" screen for a new build is following a path that no longer exists — a detail that's easy to miss if the last time you set one up was before this year.
Once that app exists, giving it a Flow trigger or action extension means implementing Flow action endpoints that Shopify's servers call, plus a trigger call using the flowTriggerReceive mutation we walked through in the triggers guide linked above — and if that custom action writes back to Shopify (adjusting stock from an external signal, for instance), it needs to handle retries the same way any reliable API integration does. We ran into exactly this with inventory writes in our piece on inventorySetQuantities now requiring an idempotency key — the same discipline applies to a Flow action endpoint that calls back into Shopify's Admin API, since Flow itself may retry a failed action call.
A decision framework, not a rule of thumb
- Stay with templates if the app you need is one of the ~300 with a Flow connector and the trigger you need is an event Shopify already fires.
- Add an HTTP request action if the logic is custom but the trigger is still a real Shopify event — order created, inventory changed, customer tagged — and you just need to reach an app with no connector, run on a rough schedule piggybacked on an existing trigger, or branch on external data.
- Build a custom app with Flow extensions only if you're on Shopify Plus and need Flow's UI itself — so non-technical staff can build and adjust the workflow — to expose a trigger or action that nothing else provides.
- Build a standalone custom app with no Flow involvement if you're not on Plus and need a genuine custom trigger, or if the logic needs to coordinate multiple systems with shared state that doesn't fit Flow's step-by-step model at all.
Who should not build anything custom
If you're running one or two automations total and one of them needs an app outside Flow's connector list, a paid connector like Zapier or Make is very likely cheaper than any custom build once you count engineering time — those tools exist precisely to bridge the apps Flow doesn't, and at low volume their per-task pricing beats a maintained integration. Custom work, whether it's an HTTP-request function or a full app, only pays for itself once you're running enough distinct automations, or automations complex enough, that a per-task connector's pricing or its own limitations start costing more than a one-time build. If you're not sure which side of that line you're on, that's a scoping conversation worth having before committing engineering time either way — this is the kind of Shopify automation and integration work we take on directly.