Most ERP-facing Make scenarios I've built or fixed fall into three shapes, and the failures I see are usually a scenario built in the wrong shape for its job — a reconciliation job wired as a single reactive webhook flow, or a real-time sync built as a nightly batch. Naming the shape up front makes the rest of the design decisions (error handling, scheduling, idempotency) fall out naturally instead of being bolted on later.
Webhook-in, write-out
The simplest shape: an event arrives (a new order, a status change) via webhook, the scenario looks up whatever context it needs, transforms the payload, and writes it to the ERP. This works well for anything genuinely event-driven and low-volume enough that a single record per execution is fine. It breaks down when the source system can burst many events at once — Make queues webhook triggers, but if your ERP write is slow, a burst can back up the queue and introduce latency nobody designed for.
{
"flow": [
{"module": "webhook:CustomWebhook", "name": "Order Created"},
{"module": "datastore:ActionSearchRecords", "name": "Dedup check"},
{"module": "http:ActionSendData", "name": "Create ERP Sales Order"}
]
}Scheduled reconciliation
For anything where correctness over time matters more than instant latency — inventory counts, price lists, account balances — a scheduled scenario that fetches the full current state from both systems and diffs them beats a purely event-driven design. Events get missed (a webhook delivery fails, a scenario is paused during maintenance); a reconciliation pass run every few hours catches drift that an event-only design would silently accumulate.
Use webhooks for low-latency updates and a slower reconciliation scenario as the safety net that catches whatever the webhook path missed. Relying on either alone leaves a gap the other would have caught.
Router fan-out for multi-destination writes
When one ERP event needs to update more than one downstream system — a new customer needs a CRM record, a billing system entry, and a support desk profile — a Router module splits the flow into parallel branches after a single fetch, rather than three separate scenarios each polling the ERP independently. This keeps the source-of-truth read to one call and lets each branch have its own error handling without one destination's failure blocking another's.
If a Router fans out to three destinations and one branch's error handler is set to Break, that branch retrying doesn't and shouldn't block the other two from proceeding — check that error routes are scoped per branch, not assumed to apply scenario-wide.
One scenario per responsibility, not one scenario per system
The instinct to build a single scenario that handles "all ERP integration" produces something unreadable and un-debuggable within a few months. Splitting by responsibility — one scenario for order import, one for inventory sync, one for invoice export — means a failure in one doesn't take down the others, and the execution history for each is small enough to actually read when something goes wrong.
Naming and folders matter more than they seem to
Once there are a dozen or more scenarios touching an ERP, a flat unnamed list becomes its own maintenance cost. Prefixing scenario names by responsibility (erp-sync-orders, erp-reconcile-inventory) and using Make's folders to group them by system pays off the first time someone other than the original author has to find and fix one at 6pm on a Friday.
Wrapping up
Match the scenario shape to the job: webhook-in-write-out for low-volume real-time events, scheduled reconciliation for anything where drift matters more than latency, and router fan-out for one event needing multiple destinations. Splitting by responsibility rather than building one do-everything scenario is what keeps a growing set of ERP automations debuggable instead of a black box.
Independent software engineer in Nairobi specialising in Acumatica customisations, Laravel backends, and tax fiscalisation integrations across East and Southern Africa.