A retailer's purchase order turned into a proper Shopify order, with its paperwork attached
When a wholesale purchase order was keyed into a form, a Make scenario of about 65 modules turned it into a Shopify order: lines matched to products by SKU, the business customer attached, payment terms and metafields set, and the order's documents fetched and filed in Google Drive with a link on the order. It is built and now switched off.
Where this applies
Brands that sell wholesale to large retailers as well as direct, and use Shopify as the one place every order lives.
- modules in one scenario
- ~65
- retry handlers along the chain
- ~20
- purchase orders mapped to Shopify orders
- 155
The problem
A brand that sells direct and through wholesale programmes wants one order book. Its own shop's orders are already in Shopify; a large retailer's purchase order arrives through the retailer's own portal, in its own format, with its own documents. Two order books means stock, invoicing and fulfilment are reconciled by hand.
Typing the purchase order into Shopify by hand is slow and easy to get wrong: the lines carry SKUs rather than Shopify's own ids, the terms are not the shop's default, and the paperwork has to follow the order.
What we built
A form as the front door
Staff key the purchase order into a Cognito form, which posts to the scenario. A router separates a new purchase order from an update to one already raised.
SKUs resolved to Shopify products
An iterator walks the lines, and each SKU is looked up in Shopify through direct HTTP calls, with a pause between requests, to find the product and variant. Aggregators rebuild the lines in the shape the order needs, and the business customer's details are fetched the same way.
The order, and its memory
The Shopify order is created, and its name and id are saved in a data store against the purchase order, so a later update finds the existing order instead of creating another. Metafields carry the purchase order's details, and payment terms are added to the order.
Paperwork fetched and filed
The purchase order's documents are fetched over HTTP and uploaded to Google Drive, and the Drive link is written onto the Shopify order, so whoever opens the order can find its paperwork.
The update path, and retries throughout
For an existing purchase order, the data store hands back the Shopify order, which is read, marked as paid and has its metafields updated, and any new documents are filed. About twenty of the steps carry a retry handler, because a long chain of API calls should survive one that times out.
The outcome
Built in 2024 and last changed in July 2025. Every scenario in the account is now switched off, and there are no runs within Make's retention window to report.
The data store that maps purchase orders to Shopify orders still holds 155 records.
Where it stops
It is switched off, so this page describes a build, not current volume. A line whose SKU is not in Shopify cannot be placed, and the purchase order still has to be keyed into the form by a person. Invoicing the fulfilled order in Xero and the other channels' order imports were separate scenarios and are not described.
Built with
- Make.com
- Cognito Forms
- Shopify
- Google Drive
- Make data store
- HTTP
Patterns used
- SKU to variant lookup
- Order id in a data store
- Documents linked on the order
- Retry on every call
Page copy drafted with AI assistance. Skofi is accountable for it. Editorial policy
Have something shaped like this?
If any part of the above resembles a problem you are living with, a short call is the fastest way to find out whether it is the same problem underneath.
What happens on the call
- 15 minutes, no deck
- We map the process on the call
- A written scope, or an honest no