Salesforce ↔ ERP Integration Patterns: Lessons from the Field

Salesforce-ERP integration is where promising projects go to die. The sales team demos a slick quote-to-cash flow, everyone nods, and then six months later the integration is down for the third time this quarter and someone is reconciling differences in a spreadsheet at 11pm. We've built and rescued dozens of these integrations. Here's what separates the ones that run quietly for years from the ones that become full-time jobs.

Pattern 1: Platform Events for near-real-time sync

Salesforce Platform Events are the right primitive for event-driven integration. When a Quote is approved in Salesforce, publish a QuoteApproved__e platform event. Your middleware (MuleSoft, Azure Integration Services, or a custom subscriber) receives the event and creates the sales order in SAP or Oracle. The key advantage: Platform Events are durable (retained for 72 hours by default), the subscriber can replay missed events, and the publisher doesn't need to know anything about the downstream system. This decoupling is what makes the integration resilient to ERP maintenance windows.

Pattern 2: Change Data Capture for bi-directional sync

When data needs to flow in both directions — product catalog from ERP to Salesforce, order confirmations from ERP back to Salesforce — Change Data Capture (CDC) is your friend. Enable CDC on the objects you need to sync (Account, Order, Product2). CDC publishes a change event for every create, update, delete, and undelete. Your subscriber processes these events and applies the corresponding changes to the ERP. The ERP side typically uses database triggers or BAPI/IDoc for SAP, or Business Events for Oracle Fusion, to publish its changes back. CDC replaces polling loops that hammer both systems unnecessarily.

Pattern 3: Canonical data model for multi-ERP environments

Organizations with multiple ERPs (common after M&A) make the mistake of building point-to-point integrations from each ERP to Salesforce. After three acquisitions you have six integrations, each with its own field mappings, error handling, and deployment process. Instead, define a canonical data model in your middleware layer — a neutral representation of Customer, Order, Invoice, and Product. Each ERP maps to/from this canonical model. Salesforce maps to/from the canonical model. You've now built a hub-and-spoke architecture that scales to N ERPs with N mappings instead of N² point-to-point connections.

Pattern 4: Idempotent writes everywhere

Network failures, ERP timeouts, and retry logic mean your integration will sometimes deliver the same event more than once. Every write operation must be idempotent: applying the same operation twice must produce the same result as applying it once. In Salesforce, use External ID fields as upsert keys — the ERP's native record ID stored on the Salesforce object. In the ERP, use Salesforce's record ID as the idempotency key. Build a deduplication log in your middleware to skip processing of event IDs you've already handled.

Anti-pattern 1: Direct database connections

We still encounter integrations that read directly from the ERP's Oracle or SQL Server database. Don't. Database schemas change without warning during ERP upgrades. You have no visibility into query performance impact. You bypass the ERP's authorization layer. And the database connection becomes a single point of failure for both systems. Always use the ERP's official API layer — BAPI/RFC for SAP, REST/SOAP for Oracle, OData for Microsoft Dynamics. It's more work upfront; it's vastly less work over three years.

Anti-pattern 2: Synchronous callouts in Salesforce transactions

Calling an ERP API synchronously from an Apex trigger is the most common integration mistake we see. The ERP is slow (300ms–2s per call), the Salesforce governor limit for synchronous callouts is 10 seconds, and if the ERP is unavailable the Salesforce transaction fails and the user sees a cryptic error. Instead: publish a Platform Event in the trigger (a fast, in-transaction operation), then handle the callout asynchronously in a triggered subscriber. The user's transaction succeeds immediately; the ERP sync happens in the background with retry logic.

Anti-pattern 3: Ignoring error handling until production

The happy path works in every demo. Error handling is what separates a prototype from a production system. Define upfront: what happens when the ERP returns a validation error? When the middleware is down for 30 minutes? When field mappings fail because a record has unexpected null values? Build a dead-letter queue for failed events. Send alerts to the integration owner (not just to a log file nobody reads). Create a Salesforce custom object "Integration Error Log" that the operations team can monitor without needing to access middleware logs.

MuleSoft vs. custom middleware in 2026

MuleSoft remains the default choice for large Salesforce-centric enterprises, especially with Anypoint's expanding Salesforce-native connectors and the Salesforce Connector for MuleSoft 4.x. For smaller organizations or teams without a dedicated MuleSoft practice, Azure Integration Services (Logic Apps + Service Bus + API Management) has matured significantly and costs 3–5× less per month for equivalent throughput. We've successfully built and maintained Salesforce-SAP integrations on both stacks. The technology matters less than the architectural discipline applied to it.