Salesforce-ERP Integration: Architecture, Patterns, and Pitfalls

The Short Answer

Connecting Salesforce to an ERP often fails, not due to technical issues with the connection itself, but because a crucial question wasn't asked upfront: Which system is the source of truth for each entity, and what happens when messages between systems are lost, duplicated, or arrive out of order? This guide frames the decision around three layers—source of truth, synchronization pattern, and error handling—and demonstrates how to choose between them based on actual business scenarios, not just what the API allows.

The recommended approach is to start with the entities (customer, product, order, invoice) rather than the tools. For each entity, define a single owner, a reasonable update frequency, and who is authorized to make changes. From there, the synchronization pattern, error handling, and required monitoring level are derived.

A natural continuation of this discussion on connecting Salesforce to ERP is found in Salesforce Architecture.

Source of Truth for Each Entity: The Question Before Any API

Before choosing a protocol or integration tool, you must answer one question for each entity: Which system decides what's correct when there's a conflict? Typically, ERP is the source of truth for inventory, pricing, invoices, and financial transactions, while Salesforce is the source of truth for customer relationships, opportunities, and sales activities. The problem begins when someone silently assumes that both directions will "sort themselves out"—leading to situations where a sales rep changes a shipping address in Salesforce while the ERP has already dispatched the shipment to the old address.

The practical solution is an entity mapping document: for each entity (Account, Product, Order, Invoice), specify the source of truth, the synchronization direction (unidirectional or bidirectional), and the required update frequency. When genuine bidirectional synchronization is needed—for example, a payment status update returning from the ERP to the Opportunity record—an explicit rule for conflict resolution is established, such as "the last update by timestamp wins" or "financial fields are always dictated by ERP."

Synchronization Patterns: Request-Reply, Batch, and Event-Driven

Three patterns cover most real-world scenarios. Request-Reply (synchronous) is suitable when a Salesforce user waits for an immediate response—for example, checking inventory availability before confirming an order. The advantage is simplicity and immediate feedback; the disadvantage is complete reliance on ERP availability at that moment, and a negative impact on user experience if the response is slow.

Batch is suitable for large-volume updates that aren't time-sensitive, such as a nightly price book synchronization or importing invoices from the previous day. This pattern is more resilient to temporary failures, but it implies a latency of hours to a day between systems—a gap that must be acceptable to the business, not just the technical team.

Event-Driven (using Platform Events, Change Data Capture, or an external message queue) is appropriate when near real-time response is needed without requiring synchronous dependency. An order status change in the ERP broadcasts an event, and Salesforce updates itself when ready—including automatic retry if it was temporarily unavailable. This is the most flexible pattern, but also the most complex to set up and monitor.

Pattern Selection Table by Scenario

In this context, the decision on synchronization type is also linked to the permissions model and data ownership—an expansion of this is presented in Salesforce Sharing and Visibility.

Middleware vs. Point-to-Point

When there's only one connection between Salesforce and ERP, a direct (Point-to-Point) connection using REST API or Named Credentials might be the quickest and cheapest solution. The problem begins when a third system is introduced—a data warehouse, shipping system, or payment platform—and then each new system requires building its own transformation logic and error handling, duplicating what already exists in the previous connection.

A Middleware layer (such as MuleSoft, Boomi, or Workato) solves this by centralizing the logic: each system connects once to the Middleware, and the Middleware is responsible for transformation, retries, message queues, and centralized monitoring. The cost is an additional infrastructure component that requires licensing, maintenance, and specialized expertise.

A practical rule of thumb: up to two-three stable connections without complex logic—Point-to-Point is reasonable. From three systems upwards, or when there is a central Governance requirement (like uniform monitoring for all integrations in the organization), the cost of Middleware is almost always justified within one to two years.

Error Handling and Idempotency

The most dangerous scenario in integration is not a complete failure but a partial failure: the message was sent, the ERP created an order, but the response to Salesforce was lost due to a timeout. If the sending system naively retries, a duplicate order is created.

The solution is an Idempotency Key—a unique identifier generated on the sending side and attached to each request. The receiving side keeps a record of identifiers that have already been processed and refuses (or returns the existing result) if the identifier already exists. Other practical principles:

• Every critical integration gets a Retry mechanism with gradual Backoff, not immediate and repeated attempts
• Messages that repeatedly fail go to a Dead Letter Queue for manual review, rather than silently disappearing
• Error logs include the full Payload of the failed message to allow manual reconstruction
• A daily or weekly Reconciliation process compares systems and identifies discrepancies that the Sync "missed"

Without an Idempotency Key and a structured Reconciliation process, every transient network problem becomes a persistent data issue that is difficult to trace weeks later.

API Limits, Security, and Monitoring

Salesforce imposes daily limits on the number of API calls (depending on license and edition), and limits on response size and execution time. An organization synchronizing tens of thousands of records a day via standard REST, call by call, will hit the limit quickly. The solution is Bulk API 2.0 for volume updates, and Composite API to reduce the number of calls in multi-step synchronous processes.

On the security side, three principles recur in every successful project:

1. Use Named Credentials and Connected Apps with OAuth, not fixed usernames and passwords in code
2. The authorization of the integration's "technical user" is strictly limited to the objects and fields it needs—not an Administrator Profile
3. Sensitive traffic (credit card numbers, bank account details) goes through a Middleware layer or Tokenization, not stored as plain text in Salesforce

For monitoring, a Dashboard should be set up that displays at least three metrics: the success rate of messages versus failures, average and median response time, and the number of records in the Dead Letter Queue. An automatic alert when the failure rate crosses a defined threshold (e.g., above 2% of messages per day) prevents an accumulating problem from being discovered only when a customer complains.

These decisions often rely on previous foundational work in information and permissions, described in Salesforce Technical Debt.

Recommended Workflow

1. Map Entities and Define Source of Truth

For each entity (customer, product, order, invoice), determine which system is authoritative in case of conflict. Without this decision, any discussion about "the right way to sync" takes place in a fog.

2. Choose a Synchronization Pattern Based on Actual Required Latency

Not every process needs an immediate response. Inventory checks before a sale do; nightly price book updates do not. Matching the pattern to the actual need saves unnecessary infrastructure costs.

3. Decide Between Middleware and Point-to-Point

The decision depends on the number of connected systems and the need for central Governance, not purely on technological preference.

4. Plan Idempotency, Retry, and Reconciliation from the Start

These are not "future enhancements" but part of the Definition of Done for any integration involving money, inventory, or orders.

5. Define Minimum Permissions for the Technical User

A dedicated Profile, not a sweeping administrator permission. Any permission change requires separate approval from functional changes.

6. Test Failure Scenarios, Not Just Happy Path

Running a test where the ERP "crashes" mid-process and measuring recovery time and whether duplicates are created, uncovers problems not visible in a quiet development environment.

7. Set Up a Dashboard and a Regular Reconciliation Process

Technical monitoring (is the server alive) is not enough; business monitoring (are order counts equal in both systems) is needed.

Example Organizational Scenario

A trading company with approximately 40,000 orders per month connected Salesforce to its ERP using direct synchronous REST calls, without Middleware. During a peak sales period, the failure rate for API calls sharply increased due to the daily call limit, and orders that failed to register in the ERP simply "disappeared"—because there was no Dead Letter Queue and no alert.

After investigation, three things were found missing: no Idempotency Key was defined, so retries sometimes created duplicate orders; there was no use of Bulk API for volume updates; and there was no Reconciliation process comparing order counts between the two systems. The solution involved transitioning to a Middleware layer with a message queue, replacing some synchronous calls with frequent Batches, and adding a daily Dashboard displaying discrepancies.

The result wasn't "zero faults"—that's an unrealistic goal—but rather a fault identification time that dropped from weeks to hours, and a process that allows fixing discrepancies the same day, rather than after a customer complains.

Common Risks and Preventive Actions

Those at an earlier stage than connection planning may find complementary background in Salesforce Flow or Apex, primarily in deciding where the transformation logic actually resides.

How to Measure Success

It's advisable to choose only three to four metrics for the first version, and to measure them before launch to have a true Baseline for comparison, not an estimate from memory.

Pre-Production Checklist

• ☐ For each entity, a single source of truth and a conflict resolution rule are defined
• ☐ A synchronization pattern (Request-Reply, Batch, or Event-Driven) is chosen for each process separately
• ☐ It has been decided whether Middleware is needed or if a direct connection is sufficient
• ☐ An Idempotency Key exists for every operation that creates a financial record
• ☐ Retry with Backoff and a Dead Letter Queue are defined for failed messages
• ☐ Daily API quota consumption has been checked against expected volume
• ☐ The technical user's permissions are limited to the required objects and fields only
• ☐ Partial failure testing has been performed, not just happy path
• ☐ A Dashboard exists for business monitoring, not just technical
• ☐ A regular Reconciliation process is defined and owned

In-Depth Notes for Implementation and Maintenance

Architect's Note: When to Change an Existing Pattern

If a nightly Batch pattern was initially chosen for simplicity but the business starts demanding near real-time inventory updates, there's no need to "blow up" the entire architecture—you can increase frequency to 15 minutes as an interim step, and only transition to Event-Driven when it becomes clear that even that isn't enough. Gradual change, accompanied by actual latency measurement, is preferable to a blanket decision made too early.

From a management perspective, the true test of a Salesforce-ERP connection is not just that it "works today," but that you can explain within five minutes why each pattern was chosen, and who is responsible for fixing it when something goes wrong. A solution that requires lengthy investigation for every issue creates a hidden operational cost that grows over time.

Where internal capacity for planning or implementing such a connection is lacking, CRM Architecture Services is the practical path forward.

Professional Resources

• Salesforce Integration Patterns — https://architect.salesforce.com/docs/architect/fundamentals/guide/integration-patterns.html
• Salesforce Data Integration Decision Guide — https://architect.salesforce.com/docs/architect/decision-guides/guide/data-integration.html
• HPI Pro – CRM Architecture — https://hpi.pro/crm-architecture
• HPI Pro – Integrations & Data — https://hpi.pro/integrations-data