Connecting Salesforce to an ERP like NetSuite, SAP, or Microsoft Dynamics is where a lot of otherwise healthy Salesforce programs quietly accumulate risk. These are the architectural patterns that scale, and the ones we avoid, drawn from integration work across all three platforms.
Why integration is where projects go wrong
CRM and ERP describe the same business from two different angles. Salesforce owns the front office: leads, opportunities, accounts, and the customer relationship. The ERP owns the back office: orders, invoices, inventory, and the general ledger. The moment money or fulfillment is involved, those two systems have to agree, and the integration between them becomes load-bearing infrastructure. Get it wrong and you get duplicate orders, mismatched revenue, and finance and sales arguing over whose numbers are right.
The reason integration is so often the weak point is that it is invisible until it breaks. A clever point-to-point connection works in the demo and in the first month of production, then a volume spike or a schema change takes it down at quarter close. The patterns below are the ones that hold up under real load and real change, which is the only test that matters.
The five patterns that work
- Pattern 1, event-driven via middleware (MuleSoft, Workato): the modern default for most integrations.
- Pattern 2, real-time API integration with retry logic and a dead-letter queue for failures.
- Pattern 3, batch ETL with reconciliation reporting for high-volume data that does not need to be instant.
- Pattern 4, change data capture with Salesforce Platform Events to propagate changes as they happen.
- Pattern 5, hybrid: real-time for the critical paths, batch for everything else.
The first pattern is the default for a reason. Routing integrations through a middleware tier decouples Salesforce from the ERP so that a change, an outage, or a schema revision on one side does not ripple straight into the other. The remaining patterns are choices you layer on top depending on latency needs and volume. Real-time API integration is right when a person is waiting on the result. Batch ETL is right when nobody is. Change data capture fits when you need to react to changes without polling. Most mature orgs end up hybrid, because most businesses have both kinds of data flow.
The three patterns we avoid
First, direct database-to-database integration. It looks simple and it is fast to stand up, but you end up bypassing business logic, validation rules, and audit trails, which means you can write data that the application layer would never have allowed. Always go through APIs so the platform's own rules stay in force.
Second, brittle point-to-point integrations that hard-code source-to-target mapping between the two systems directly. Each one is fine in isolation. A handful of them becomes a web that no single person understands and that breaks whenever either system changes. Use a middleware tier and your future self will thank you. Third, nightly full-data dumps that overwrite everything. They are slow, they obscure what actually changed, and they make conflicts impossible to reason about. Use incremental sync that moves only what changed.
Architectural decisions to make before you start
Before any integration project, answer four questions in writing and get the business to agree to the answers. What is the system of record for each entity, so there is one authoritative source for every field? What is the latency tolerance for each data flow? Who owns reconciliation when records inevitably do not match? And what is the rollback plan when a sync goes wrong?
These questions are unglamorous and they are where projects are won or lost. Skipping any one of them does not save time, it defers the cost to the worst possible moment, usually a quarter close when finance and sales discover their numbers disagree and nobody can say which system is right. Settle them up front, choose the pattern that fits each flow, and the integration becomes infrastructure you can trust rather than a recurring fire.