If you are deciding whether Shopify Flow or Shopify Functions should own a store rule, choose by when the rule must run and who must be able to change it. Flow is usually the right owner for post-event automation that operations can edit in admin. Functions are usually the right owner when Shopify must evaluate deterministic logic inside the cart or checkout path. Putting the same rule in both layers—or rebuilding Scripts-era logic as Flow tags—creates silent conflicts and hard-to-debug margin mistakes.
This article gives you a Commerce Logic Placement Ladder, a Logic Placement Scorecard, and a worked example so you can assign each rule to the correct layer before you commission development work through website and SaaS development.
Key takeaways
-
Shopify Flow starts from a trigger, evaluates conditions, and runs actions after something happens in the store or an app. It is designed for merchant-editable automation.
-
Shopify Functions inject backend logic into Shopify’s commerce execution path—discounts, delivery options, payment customization, cart transforms, validation, and related targets.
-
Any plan can use public App Store apps that contain Functions. Custom apps that contain Function APIs require Shopify Plus, and some capabilities are Plus-only.
-
Flow can call external systems with Send HTTP Request on Grow, Advanced, and Plus. Functions generally run without open network access; limited network access exists mainly for eligible enterprise custom apps.
-
This is not the same decision as what to rebuild after Scripts stopped. That article prioritizes migration urgency. This one places ongoing logic correctly between Flow, Functions, and app backends.
What each tool actually owns
Teams often treat Flow and Functions as interchangeable “automation.” They are not. The ownership contract is different.
Shopify Flow: post-event, merchant-owned workflows
According to Shopify’s Flow documentation, a workflow combines a trigger, conditions, and actions. A trigger can be an internal store event, a schedule, or an external app event. Conditions decide whether actions run. Actions can change store data, notify people, use connectors such as Slack or Google Sheets, or send HTTP requests to external services.
Flow is strongest when an operations lead should be able to open the workflow, change a threshold, and turn the automation on or off without a code deployment. Typical fits include tagging risky orders, notifying finance when an order exceeds a value, holding fulfillment for review, or syncing a status into another tool after the order already exists.
Shopify also documents real limits. High-volume triggers multiply expensive Get data actions. Multiple workflows on the same trigger can compete for API capacity. Get data actions are designed to return a maximum of 100 objects. Those constraints matter when someone tries to use Flow as a real-time pricing engine.
Shopify Functions: synchronous commerce decisions
Shopify Functions customize Shopify’s backend logic during key purchase flows. Shopify documents Function targets for work such as discounts, delivery customization, payment customization, cart transforms, fulfillment constraints, location rules, and cart and checkout validation. Shopify invokes Functions as needed in the customer journey; merchants do not call them by URL.
Function logic compiles to WebAssembly and must stay within resource limits because slow Functions can delay checkout. Shopify does not allow nondeterminism such as randomizing or clock-based behavior inside Functions. Direct open networking is not the default model; network access is a limited, requestable capability primarily associated with eligible enterprise custom apps, with Shopify performing the HTTP call for supported fetch targets.
Plan reality matters. Stores on any plan can install public App Store apps that contain Functions. Only Shopify Plus stores can use custom apps that contain Shopify Function APIs. If your rule needs a custom Function and you are not on Plus, the practical path is usually a public Function-based app, a native setting, or a different architecture—not “do it in Flow during checkout.”
The Commerce Logic Placement Ladder
Use this ladder to place each rule. Climb only when a lower level cannot enforce the required timing or ownership contract.
|
Level |
Owner |
Use when |
Do not use when |
|
L0 — Native admin |
Shopify discounts, shipping profiles, markets, B2B catalogs, and built-in checkout settings |
The rule already exists as a supported native configuration |
You need custom composition, validation, or cross-object logic native tools cannot express |
|
L1 — Shopify Flow |
Trigger → condition → action workflows in admin |
Work must happen after an event, and ops should edit it without deploys |
The buyer’s current cart or checkout result must change synchronously |
|
L2 — Public Function apps |
App Store apps that already ship Functions (and related checkout extensions where relevant) |
You need checkout-path logic but not a custom Function codebase |
Your rule is unique enough that configuration alone cannot express it safely |
|
L3 — Custom Functions |
Custom app Functions on Shopify Plus (where required) |
Deterministic rules must run inside Shopify’s supported Function targets |
You need durable multi-system orchestration, free-form network calls, or frequent non-technical rule rewriting |
|
L4 — App backend + signals |
Hosted app, webhooks, Admin API, and optional Flow as the merchant control layer |
The process needs retries, reconciliation, external IDs, or state across minutes or days |
A supported Function target already owns the decision more safely and simply |
A mature store often uses several levels at once. The anti-pattern is giving one process two owners—for example, a Function that discounts a cart and a Flow that later “corrects” the same order with tags and manual refunds because the discount rule never belonged in post-purchase automation.
Logic Placement Scorecard
Score each proposed rule from 0 to 2 on the six factors below. Higher totals push you up the ladder toward Functions or an app backend. Lower totals keep you in native settings or Flow.
|
Factor |
0 |
1 |
2 |
|
Timing |
After order or customer event only |
Thank you / order status / account side effects |
Must change cart, discount, delivery, payment, or validation now |
|
Buyer money risk |
Internal labels or notifications only |
Delayed ops impact if wrong |
Wrong price, shipping offer, or checkout block if delayed |
|
Data locality |
Needs frequent live external decisions |
Mixed Shopify data plus occasional external sync |
Deterministic over cart, customer, and metafield data Shopify can supply |
|
Edit ownership |
Ops must change rules weekly without engineering |
Occasional admin configuration is enough |
Policy is engineering-owned and release-controlled |
|
Plan path |
Need custom Function APIs without Plus eligibility |
Public Function apps are enough |
Plus custom Function path is available when required |
|
Durability |
Needs retries, reconciliation, and external system state |
Simple HTTP handoff after the event is enough |
No durable process—only a one-shot decision or tag |
Interpret the total:
-
0–3: Stay at L0–L1. Prefer native settings, then Flow.
-
4–6: Prefer L2 public Function apps, or Flow plus a carefully scoped HTTP handoff. Re-check whether native tools already cover the need.
-
7–9: Plan for L3 custom Functions when Plus-eligible, or a specialist Function app if custom development is not justified. Keep Flow for surrounding notifications—not as the price engine.
-
10–12: Split ownership. Put the synchronous decision in Functions where supported, and put durable orchestration in an app backend. Use Flow as the merchant-visible control or alerting layer when useful.
If “Edit ownership” scores 0 and “Timing” scores 2, you have a conflict: ops wants weekly edits, but checkout needs synchronous enforcement. Resolve that before building. Usually the answer is a Function or Function-based app with merchant configuration fields—not a Flow workflow pretending to be checkout logic.
Worked example: wholesale threshold and VIP shipping
Consider a hypothetical mid-market brand with three rules on a sticky note:
-
If an order is over $500, Slack finance and tag the order for review.
-
Hide express shipping below a cart subtotal, and rename the remaining option for VIP customers.
-
After payment, create a sales order in the ERP and retry until the ERP acknowledges it.
Rule 1 scores low on timing and buyer money risk. It belongs at L1 Flow: order created trigger, condition on total, actions for tag and Slack connector. Ops can change the $500 threshold without a release.
Rule 2 scores high on timing and buyer money risk. Delivery customization is a Function concern. A public delivery customization app may be enough at L2. If the VIP rename logic depends on customer tags and metafields unique to the brand, L3 custom Functions on Plus can be justified. Flow should not hide shipping methods after checkout has already presented them.
Rule 3 needs durable retries. Flow’s Send HTTP Request can start a handoff on Grow, Advanced, or Plus, but a reliable ERP sync usually needs an app backend that owns acknowledgements, dead-letter handling, and reconciliation. Scorecard durability stays low for Flow-only ownership. Place the decision at L4, optionally with Flow notifying the team when retries exhaust.
The useful output is not “automate everything in Flow” or “rewrite everything as Functions.” It is a one-page placement map: three rules, three owners, zero duplicated enforcement.
Common failure patterns
-
Using Flow as a discount engine. Flow runs after events. It cannot safely replace a discount Function that must calculate during the buyer journey.
-
Using Functions as a general integration worker. Functions are constrained, deterministic, and performance-sensitive. Broad network orchestration and multi-day state belong in an app backend.
-
Duplicating the same policy in two layers. A Function applies one shipping rule while Flow later tags exceptions based on a different spreadsheet threshold. Margin reports then disagree with what customers saw.
-
Ignoring plan and app distribution rules. Custom Function apps require Plus. If you are not eligible, redesign around public Function apps or native tools instead of assuming Flow can fill the gap.
-
Building fragile high-volume Flow graphs. Shopify’s optimization guidance warns that expensive Get data actions on frequent triggers can throttle work and create conflicting parallel workflows.
When this advice does not apply
If your need is primarily visual checkout branding or app blocks on thank you and order status pages, start with the checkout and accounts editor rather than inventing Flow or Function logic. Shopify documents that standard checkout customizations are available on Basic and higher, while apps that customize information, shipping, and payment steps require Shopify Plus.
If you are still recovering from Scripts shutdown work, prioritize revenue-critical Function replacements first using a rebuild queue, then return to this placement ladder for net-new automation. And if the real question is whether to buy an App Store product or commission a custom build, use a build-versus-buy process such as buy a Shopify app or build custom after the placement decision is clear.
Recommended next steps
-
Inventory every custom rule as a one-line statement: trigger or decision point, desired result, who edits it, and what breaks if it is late.
-
Score each rule with the Logic Placement Scorecard and assign an L0–L4 owner. Do not skip L0.
-
Separate synchronous checkout decisions from post-event ops workflows. Write that boundary into your backlog so developers and operators stop arguing past each other.
-
For Flow candidates, install or review Flow, confirm plan access for HTTP actions if needed, and combine overlapping same-trigger workflows before launch.
-
For Function candidates, confirm whether a public Function app is enough or whether Plus custom Functions are required, then prototype against Shopify’s documented Function targets and resource limits.
-
Only then schedule development. Architecture first, implementation second.
If you want help turning that placement map into a Shopify build plan—Flow workflows, Function apps, or a durable backend—book a growth strategy session with Oasbit.
