Workflow
Store order → fulfilment sheet, with the line-item cost trap
A paid order is fanned out into one row per line item. The purpose of this test was to measure how consumption scales with line items, because that is where the cost surprise lives.
No link on this page is an affiliate link. We are in the programme below, so we could earn a commission elsewhere on this site — but not from anything on this page. We recommend free tools where they are the better answer, including ones that earn us nothing.
- Make.com: 35% of subscription payments for 12 months; extra-operation purchases do not earn commission (terms verified 2026-09-24)
The problem this addresses: I copy ecommerce orders into a fulfilment spreadsheet every day.
The steps
- Receive the paid-order payload.
- Split the order into one item per line. This is the step that multiplies cost. An order with ten items is not one unit of work.
- Append one row per line item.
- Send one summary notification per order, not per item. Getting this wrong means ten notifications for one order.
What we measured
What this measurement is, and what it is not
These numbers come from running this workflow’s logic against a local test stack over real HTTP, using synthetic data. They describe the workflow design — how many units of work it costs and how it behaves when things go wrong. They are not measurements of Make, n8n or Pabbly, and nothing here should be read as a claim about any vendor’s product.
We tested itCost scales with line items, not orders. Measured across three synthetic orders:
| Line items in the order | Units of work | Run time |
|---|---|---|
| 1 | 3 | 5ms |
| 3 | 5 | 15ms |
| 10 | 12 | 16ms |
The formula: units of work = line items + 2 (one fetch, one append per item, one summary notification). A ten-item order therefore costs four times a one-item order — and your customers decide which you get.
What a mid-run failure leaves behind
We forced a failure at line 5 of 10. 4 rows were already written and stayed there. The order looks partly fulfilled and nothing marks it incomplete.
Platform status
n8n (self-hosted Community) — Community (self-hosted)
- Not tested. n8n Community could not be installed on this machine: the npm install exhausted available disk space and failed. See 15_qa_report.md for the exact figures. Workflow JSON has been authored and is ready to import, but IT HAS NOT BEEN RUN, so no n8n result is claimed.
- We do not describe untested workflows as working. This section will be updated once the test is possible.
Make.com — Free
- Not tested. Requires an account, which the agent is not permitted to create. Owner action needed before this platform can be tested.
- We do not describe untested workflows as working. This section will be updated once the test is possible.
Pabbly — Free
- Not tested. Requires an account, which the agent is not permitted to create. Owner action needed before this platform can be tested.
- We do not describe untested workflows as working. This section will be updated once the test is possible.
Limitations and failure cases
- Consumption scales with line items, not orders. The pricing page talks about operations; your customers decide how many you use.
- Partial failure is possible: some line items written, some not, leaving a half-entered order that looks complete.
- Address formatting varies by platform and country; a single address field is not reliable for shipping labels.
Failure cases we induced deliberately
- A ten-line order — tested, and the consumption is measured in the results below.
- Failure midway through the split — tested against a deliberately failing endpoint; the run log shows what was written before the failure.
Access and permissions this needs
- Read access to orders.
- Write access to the fulfilment sheet.
Security and privacy
- Order payloads contain customer names and full shipping addresses. This is the most sensitive data in the whole cluster.
- All testing here used synthetic orders with example.invalid addresses. No real store was connected.
- Never test an order workflow against a live store. A mistake here ships a real parcel to the wrong place.
Free options, and when you would have to pay
- Every major platform exports orders to CSV free. Under roughly ten orders a day that is genuinely the better answer.
What pushes you onto a paid plan: Volume. A free tier's monthly allowance is consumed quickly once each order costs several units instead of one.
The limits of this test
What we can say
- We measured how consumption scales from 1 to 3 to 10 line items on identical logic.
- We can show what a partial failure leaves behind, because we caused one.
What we cannot say
- We cannot state Shopify's or WooCommerce's real webhook behaviour — we used synthetic payloads, not a real store.
- We cannot claim error-rate reductions for real sellers. We have no sellers.