Salesforce ↔ ERP Integration Patterns: Lessons from the Field

Salesforce-ERP integration can turn a promising workflow into a persistent operational burden when ownership, retries, mappings, and reconciliation are designed late. This article summarizes patterns Synairo uses when assessing or delivering these integrations.

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

Salesforce Platform Events are one supported primitive for event-driven integration. For example, an approved quote can publish an event that middleware consumes before calling the ERP. Salesforce retains platform events and Change Data Capture events for 72 hours, allowing a subscriber to retrieve events within that window. The design still needs durable checkpoints, idempotency, monitoring, and recovery behavior outside the event bus.

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) can publish Salesforce record changes to a subscriber. The ERP return path must use interfaces supported by the customer's exact product and version. CDC can reduce polling on the Salesforce side, but it does not by itself create a reliable bidirectional integration.

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

Direct reads from an ERP database can couple an integration to an internal schema, bypass application authorization, and create operational risk during upgrades. Prefer interfaces documented and supported for the customer's exact ERP product and version. Any exception should have an explicit owner, security review, change contract, and recovery plan.

Anti-pattern 2: Synchronous callouts in Salesforce transactions

Calling an ERP API synchronously from a user-facing Salesforce transaction couples the user's outcome to the remote system's latency and availability. Where the business process permits asynchronous completion, publish an event or enqueue work and handle the remote call with explicit retry and error behavior. Confirm platform limits and transaction semantics for the chosen Salesforce release and mechanism.

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 can fit Salesforce-centric enterprises that already operate the Anypoint platform. Azure Integration Services or custom middleware may fit a different operating model. Compare total cost, team skills, support ownership, throughput, observability, and failure recovery using the customer's actual workload; generic cost ratios are not reliable procurement guidance.