Most guides to make workflow automation walk through the happy path: an order arrives, a module fires, a Slack message appears. The part they leave out is what the scenario does on its second run of the same order. That is the step most teams get wrong, and it is what this page is built around: a Shopify workflow in Make that keeps a memory of what it has already done, so a retry, a re-run or a slow API call cannot double-tag a customer or send the same email twice.
This article is written for operators at $3M to $30M revenue on Shopify Plus or a paid subscription platform, where a duplicated action reaches real customers. If you are below that floor, Shopify’s built-in Flow and a couple of native app integrations will cover you, and a Make scenario is more infrastructure than you need.
What is a Make scenario, and how does it differ from a Zap or an n8n workflow?
A scenario in Make is a canvas of modules connected left to right. The first module is the trigger, the rest are actions, and data moves between them as bundles. Each module run counts towards your usage, and the count is per module run rather than per finished workflow. That single fact shapes how you build.
In practice the three tools feel different in the places that hurt. Make shows you the data at every module on the canvas, which makes debugging fast, and it has routers, iterators and aggregators as first-class modules. Zapier is linear by default and hides more of the plumbing, which suits short chains and non-technical owners. n8n gives you the most control and can be self-hosted, at the cost of you running it. The detailed trade-offs are in the Make versus Zapier comparison, the n8n versus Zapier breakdown and the Zapier automation guide.
One opinion a vendor would not write: Make’s canvas makes complicated workflows look tidy, and that is a hazard. A scenario with fourteen modules and three routers is readable on a screen and still impossible to reason about when it misbehaves at 2 a.m. Keep each scenario to one outcome.
What do you need before you start?
Have four things ready before you open the editor:
- A Shopify admin login that can create apps or approve connections, held by someone who will still be there in a year.
- A written list of the systems the scenario touches, with the one system that owns each piece of data marked.
- A place failures will go: a shared inbox or a Slack channel with a named person watching it.
- A test order you can create at will, ideally on a development store or with a clearly marked test customer.
The error handler is the item people skip. An error handler that emails nobody is the same as no error handler.
How do you build a Shopify workflow in Make, step by step?
The steps follow the order that produces a scenario you can hand to someone else. Each step names the Make setting involved, because the setting names are what you will search for when something breaks.
Step 1: Write the workflow as a sentence before you open Make
Write one sentence: “When [Shopify event] happens, do [one outcome], and [system] owns the result.” For example: when an order is created with a wholesale tag, create a record in the finance sheet, and the finance sheet owns that record.
If the sentence contains “and also”, you have two scenarios. Splitting them costs nothing extra to build and pays for itself the first time one of them breaks while the other keeps running. It also keeps the execution history readable, because every run in a scenario’s history then means the same thing.
Step 2: Connect Shopify with the narrowest access that works
Create the Shopify connection from the first Shopify module you add. Grant only the scopes the scenario needs: reading orders is a different grant from writing products or customers. Name the connection after the store and the purpose, such as “Store name, orders read”, rather than leaving the default label.
Two connections that look identical in a dropdown are how a scenario ends up pointed at the wrong store. On a multi-store setup this matters more than any other naming decision you make in Make. If you do not know which scopes a module needs, the module’s help panel and Shopify’s Admin API documentation list them.
Step 3: Choose a webhook trigger, not a schedule
Make offers two ways to hear about a Shopify event. A watch-style module polls Shopify on the schedule you set. A webhook trigger is called by Shopify the moment the event happens. For orders, use the webhook. It reacts sooner, and it avoids spending module runs on polls that find nothing.
The trade-off is that a webhook has no built-in cursor. If the scenario is switched off or errors out while events arrive, you cannot assume they will be replayed. A polling module remembers where it stopped and can catch up, which is a genuine advantage after downtime. Whichever you choose, set the scenario’s scheduling to run immediately for webhooks and turn on incomplete executions in the scenario settings, so a failed run is stored for you to inspect and re-run instead of vanishing.
Keep “Sequential processing” in mind too. With it off, Make can process several webhook events at once, which is faster and also means two events for the same customer can race each other. For any scenario that reads a record and then writes back to it, turn sequential processing on and accept the slower throughput.
Step 4: Filter and route before you spend operations
Put a filter on the connection between the trigger and the first action. A filter that stops the wrong orders early is the cheapest optimisation available, because a bundle that stops at a filter does not run the modules behind it.
Then add a router if the outcome differs by order type. The setting to get right is the fallback route. Every router should end with a route marked as the fallback, and that route should not be empty. Send it to your failure channel with the order number, so an order that matches none of your rules is noticed instead of quietly ignored. Someone always invents a new discount code, sales channel or tag that your rules did not anticipate.
Watch the iterator. If a scenario iterates over an order’s line items and calls another app for each one, its cost scales with basket size. Model the cost against your largest sale-day baskets, not your average order, and check current plan units on Make’s own pricing page before you commit.
Step 5: Give the scenario a memory of what it has processed
Make will happily run the same order twice. It happens when you re-run a failed execution, when a webhook is delivered more than once, when a Break handler retries a module partway through a chain, or when someone clones and enables a scenario without disabling the original. Modules that create things (a row, a tag, a customer note, a ticket, an email) do not check whether the thing already exists.
The fix is a Make data store. Create one called something like “processed_orders”, with the order ID as the key. Immediately after the filter, add a Get a record module against that store. Follow it with a filter that continues only if no record was found. As the last write in the chain, add a Save a record module that stores the order ID. Place that save last, so a failure halfway through leaves the order unmarked and eligible for retry.
Consider the failure that this order of operations creates. If the final save itself fails after every earlier action succeeded, the retry will repeat those actions. To contain that, make the earlier actions idempotent where you can: update a tag instead of appending, upsert a row by order ID instead of inserting. A duplicate check is a second line of defence, not a licence to write non-idempotent modules.
Delete old records from the store on a schedule. A store that grows without bound eventually hits its size limit, and then the duplicate check itself starts failing. Read the current limits in Make’s documentation for your plan.
Step 6: Attach an error handler to every module that writes
A module without an error handler stops the whole scenario when it fails. That is the right behaviour for a broken connection and the wrong behaviour for a single bad record. Choose the handler by the kind of failure:
| Failure | Handler | Why |
|---|---|---|
| Rate limit or brief outage | Break, with retry attempts and an interval set | Stores the bundle and retries it later without holding up other runs |
| One bad record, safe to skip | Ignore | Lets the run continue, but only if the skipped record is logged elsewhere |
| Partial write you cannot leave half-done | Rollback | Reverses modules that support it and stops the run |
| Failure you must see, then move on | Resume, with a fallback value | Substitutes a safe value and continues |
Read the table as a decision aid, not a rule. Break is the useful one for Shopify, because Shopify’s API rate limits are the failure you will actually meet during a sale. Break only works well if incomplete executions are enabled, which is why that setting appears in Step 3.
Ignore deserves suspicion. It turns a visible error into an invisible gap. If you use it, the same branch must write the skipped record to your failure channel first.
Finally, decide who is told. Add a module at the end of your handler that posts the scenario name, the order number and the error message to a channel with a named owner. Then write down who that is. A scenario nobody watches has stopped working before anyone notices.
Step 7: Test with a failure, then turn the scenario on
Testing the happy path proves the least. Run the scenario once against your test order and confirm the outcome. Then do three deliberate failures:
- Run the same order through a second time and confirm nothing is duplicated.
- Disconnect the destination system’s connection and confirm the handler fires and the failure message reaches the named person.
- Send an order that matches no router rule and confirm it lands in the fallback route.
Only then switch on scheduling. Afterwards, open the execution history the next morning and look at real runs. The first day of live traffic finds the tag spelt differently, the order with no email address, the customer with two addresses.
What breaks when Make workflow automation runs at volume?
Three things break first, and none of them is a bug in Make.
Sale-day bursts. Webhook events arrive in clumps, and the destination system’s rate limit is usually lower than Shopify’s. Break with retries handles this when configured, and an unhandled scenario simply fails a fraction of orders with no pattern you can see. Load-test with a replay of a past busy hour, not a single test order.
Cost drift. Usage pricing means that adding one module to a busy scenario raises the bill in proportion to order volume. Before you add a step, multiply your daily order count by the module runs it adds. Make’s plan units and allowances change, so read the pricing page rather than trusting a blog post, including this one.
Ownership drift. The person who built the scenario leaves, and the connection was authorised under their login. The scenario keeps running until the token expires, then stops without an alarm. Put connections under a shared operations account and record which scenario depends on which connection.
How do you know it is working?
Do not rely on the absence of error emails. A scenario that stops receiving events reports nothing, because nothing failed.
Build a heartbeat: a second small scenario that runs once a day, counts orders Shopify created in the previous day, counts the entries in your processed-orders data store for the same period, and alerts you if they differ. It costs a few module runs a day and catches the failure the error handler cannot see: events that never arrived.
Then review the execution history weekly for the first month. Look at incomplete executions specifically. Every one is an order that did not finish, and a growing pile is the earliest warning you get.
Where should you not use Make?
Do not use Make for anything where a wrong action costs more than a person’s minute. Refunds without human approval, edits to a live payment or subscription record, and messages sent to a whole customer list belong behind a human check. Let the scenario assemble the case and post it for approval.
Do not build on data you already know is unreliable, such as a product feed with inconsistent tags or a customer list with duplicates. The scenario will apply your rules faithfully to bad input. Fix the source first.
Be cautious with AI steps too. If you add a model call inside a scenario, validate what comes back, restrict it to a fixed set of allowed outputs, and keep an approval step in front of anything irreversible. The wider question of where AI steps help and where they fail is covered in AI workflow automation for ecommerce.
If your scenarios are multiplying, breaking in ways nobody owns, or starting to include AI decisions, that is an AI agents and automation problem rather than a Make problem: it needs a defined owner, tested failure paths and a controlled way to grow. Pointerflow’s AI agents service is built for that stage.
Sources
- No external figures are quoted. This article is written from Make’s documented scenario, router, error-handler and data store behaviour; check Make’s current documentation and pricing page for plan limits and units.