.png)
Most ERP automation content is written by ERP vendors. It covers how to use automation features inside the ERP: workflow approvals, built-in alerts, native report scheduling.
That is useful. But it is not what most mid-market manufacturers are actually stuck on.
What they are stuck on is the gap between the ERP and everything else: the 3PL that sends shipment updates via EDI, the WMS that runs on a different database, the Shopify storefront that needs inventory synced, the Retool dashboard that ops supervisors want to see real-time data in.
Those connections are not built into the ERP. They require an integration layer. And building that layer the right way, without touching your ERP configuration or risking your existing data, is what this post covers.
The most important design decision in ERP integration is this: n8n (or any integration tool) should read from your ERP frequently and write back to it only on confirmed, specific events.
Reading is low-risk. A GET call to the NetSuite REST API that retrieves current inventory levels does not change anything. It cannot break your ERP. It can be retried if it fails.
Writing is where mistakes happen. A POST call that creates a purchase order, updates a sales order status, or marks a goods receipt as complete has real consequences if it fires incorrectly. That is why writes should be gated: only triggered by a confirmed event, only with validated data, and always with a logging step that records what was written and when.
This principle shapes every integration described in this post.
These are the four ERP integration points that deliver the highest ROI for mid-market manufacturers, in rough order of complexity:
The problem: Inventory levels in the ERP are the source of truth. Shopify shows customers what is available. When those two are out of sync, overselling happens or products go offline unnecessarily.
What the workflow does:
n8n runs on a scheduled trigger (every 15 to 60 minutes, depending on how dynamic your inventory is). It calls the ERP API to pull current on-hand quantities for relevant SKUs. It compares those quantities against current Shopify inventory levels. Where they differ, it calls the Shopify Admin API to update inventory.
No manual sync. No spreadsheet export. The ERP remains the source of truth and Shopify reflects it automatically.
Write rules:
ERP API calls used: Inventory item GET by SKU or location
The problem: When a sales order is confirmed in the ERP, someone has to send it to the warehouse or 3PL. Many manufacturers do this by email or by manually exporting a pick list. That creates delays and introduces transcription errors.
What the workflow does:
n8n watches the ERP for sales orders that move to a confirmed/approved status. When that status change is detected, n8n retrieves the order details (line items, quantities, shipping address, priority flag) and sends them to the 3PL or WMS via their API or a structured EDI file.
Optionally, n8n can write a fulfillment status back to the ERP when the 3PL confirms the shipment, updating the sales order with tracking information.
Write rules:
ERP API calls used: Sales order GET by status filter, sales order PATCH for tracking update
The problem: ERP data is accurate but inaccessible to people who do not live in the ERP. Supervisors on the floor, ops managers in meetings, COOs reviewing daily metrics, all of them need visibility into production and inventory data without waiting for a report to be emailed.
What the workflow does:
This is less of a trigger-based workflow and more of a data pipeline. n8n runs on a schedule (every 5 to 30 minutes) and pulls key operational metrics from the ERP:
That data is written to a lightweight database (a Postgres table or Airtable, depending on what is already in use) that Retool reads from. The Retool dashboard refreshes from that database, showing supervisors a live operational view without any ERP logins or report navigation.
Write rules:
ERP API calls used: Multiple GETs across production, inventory, purchasing, and order modules
The problem: ERPs generate exceptions constantly but surface them poorly. A production job that is two days late, a raw material that has dropped below reorder point, an invoice that has been sitting unapproved for five days. These things exist in the ERP but nobody knows about them until they become bigger problems.
What the workflow does:
n8n runs scheduled checks against the ERP for exception conditions:
When a condition is met, n8n sends a structured alert to the relevant Slack channel or email distribution. The alert includes the specific record, the condition that triggered it, and a direct link to the ERP record if the ERP supports deep links.
Write rules:
ERP API calls used: Multiple GETs with filter conditions by status, date, and quantity
All four workflows above assume the ERP has a documented REST API with support for the relevant modules. Current status of the most common mid-market manufacturing ERPs:
ERPs still on SOAP/XML web services or that have no external API are a harder case. They can be integrated via scheduled database reads or file exports, but the workflow is less clean and the maintenance overhead is higher. If your ERP is in that category, it is worth flagging it as a constraint when evaluating automation scope.
Four things are required before any of these integrations can be built:
1. API credentials with the right permissions Most ERP APIs require a dedicated integration user with read/write permissions scoped to the relevant modules. Your ERP admin needs to set this up. It is typically a one-hour task but requires someone with ERP admin access.
2. A test environment Building against your production ERP is a risk. A sandbox or developer instance of the ERP lets you test the integration without touching live data. Most ERP vendors provide sandbox access; check your license.
3. Documented process logic The automation cannot make decisions it does not know about. Before building the inventory sync, document the threshold rules. Before building the exception alerts, define what counts as an exception and who should receive it. This documentation does not need to be formal, but it needs to exist before the build starts.
4. An internal owner Each integration needs a named person who understands what it does and can flag when something is wrong. That person does not need to be technical. They need to be the subject-matter expert for the workflow, know that the automation exists, and know how to escalate when it stops behaving as expected.
Each integration described above shares infrastructure:
This is the compound effect of treating ERP integration as a program rather than a project. The first integration is the hardest. Every subsequent one builds on infrastructure already in place.
If you want to know which integration to start with based on your current setup, the Flow Kaizen guide includes a scoring framework that factors in your ERP's API capability, your current manual time investment by workflow, and your internal ownership situation.
.png)
