Salesforce and ERP Integration: SAP, Oracle, and the Boundaries of Each

The Natural Boundary Between Salesforce and ERP

Salesforce and ERP systems serve fundamentally different purposes. Salesforce is designed to manage relationships, interactions, and the pipeline of value: prospects becoming customers, opportunities becoming orders, cases becoming resolutions. ERP is designed to manage the execution and accounting of that value: orders becoming shipments, shipments becoming invoices, invoices becoming revenue recognised on the balance sheet.

The natural boundary sits at the point of order creation. Everything upstream of a committed order — lead management, opportunity management, quoting, configuration — belongs in Salesforce. Everything downstream — order fulfilment, inventory management, financial accounting, manufacturing scheduling — belongs in ERP. The integration boundary is the order handoff.

In practice, this boundary is contested. Sales leaders want order status visible in Salesforce. Finance wants contract value visible in ERP. Service teams want billing history accessible without leaving Salesforce. Each of these is a legitimate need, and each can be satisfied without moving the system of record — by surfacing read-only data from ERP in Salesforce via integration, rather than by duplicating data ownership.

Six Data Boundary Decisions

Before any integration work begins, six data boundary questions must have explicit, documented answers. These decisions drive everything downstream: the integration patterns chosen, the middleware selected, the governance processes established.

1. Account/Customer Master. Is the customer master in Salesforce (Account), in ERP (Customer/Business Partner), or in a third MDM system? This determines which system gets written first when a new customer is onboarded, and which system's record governs in case of conflict. Most organisations give Salesforce ownership of the prospect/customer relationship pre-order, and ERP ownership post-order — but the synchronisation between them must be bidirectional and conflict-managed.

2. Product/Price Master. ERP systems typically own the product master (material master in SAP, items in Oracle). Salesforce CPQ requires product and pricing data. The decision: does Salesforce replicate the ERP product master, or does it maintain its own? Replication keeps pricing consistent but requires synchronisation. Independent maintenance allows flexibility but creates divergence risk. Most large organisations replicate from ERP to Salesforce, with Salesforce unable to create products that don't exist in ERP.

3. Order Status. Who creates the order? If Salesforce CPQ is quoting and the quote converts to an order, does Salesforce create an order record in ERP (via integration), or does a human re-key the order in ERP? The "Salesforce creates order in ERP" model is operationally elegant but integration-complex. The "human re-keys" model is operationally wasteful but simpler to implement. For high-volume order environments, automation is essential; for low-volume, bespoke orders, manual handoff may be acceptable.

4. Inventory Availability. Sales teams using CPQ need to know if the product they are quoting is available. This requires a near-real-time call to ERP inventory systems. The integration is typically a synchronous callout from Salesforce to an ERP API. Latency, availability, and what to show the user when the ERP system is unavailable must be designed explicitly.

5. Invoice and Payment Status. Service agents handling billing queries need invoice status. The options: replicate invoice data to Salesforce in batch (simple but stale), provide a real-time lookup from Salesforce to ERP (fresh but complex), or open a deep link to ERP in the service agent's browser (simple but breaks workflow). The right answer depends on query volume and latency tolerance.

6. Credit and Risk Data. Finance teams in ERP manage credit limits and risk flags. Sales teams need to know if a customer is on credit hold before processing a quote. This is a Tier 1 integration requirement — the data must be current and available. Design this integration with a defined fallback behaviour: what does the system show if ERP is unavailable?

Four Integration Patterns

Pattern 1 — Request/Response (Synchronous). Salesforce makes an API call to ERP and waits for a response within the user's interaction. Used for: inventory availability checks, credit limit verification, order submission confirmation. Requirements: ERP must expose a stable API, response time must be under 5 seconds, circuit breaker pattern required to handle ERP unavailability gracefully.

Pattern 2 — Event-driven (Asynchronous). A business event in one system triggers a message that the other system processes. Salesforce Change Data Capture (CDC) or Platform Events are typically the Salesforce producer. SAP Business Events or Oracle Integration Cloud are typical ERP consumers/producers. Used for: order status updates, customer record synchronisation, invoice creation notifications. Requires a message broker (MuleSoft Anypoint, Azure Service Bus, or similar) to handle ordering, retry, and dead-letter queuing.

Pattern 3 — Batch ETL. Scheduled data extraction and load, typically nightly. Used for: product master replication, historical order data, financial period data. Simplest to implement; highest latency. Appropriate only for data that does not need to be current within the business day.

Pattern 4 — Salesforce-Initiated Write-Through. An action in Salesforce (quote approval, opportunity close) triggers a write to ERP through middleware. Used for: order creation, customer provisioning. The most technically complex pattern — it requires ERP API stability, error handling, and a compensation mechanism (what to do in Salesforce if the ERP write fails).

SAP-Specific Considerations

SAP introduces specific technical and organisational considerations. On the technical side: SAP S/4HANA exposes OData APIs (via SAP API Business Hub) that are well-documented and stable — prefer these over direct BAPI/RFC calls, which are lower-level, harder to version, and require more SAP-side maintenance. For on-premise SAP, the SAP Integration Suite or an on-premise MuleSoft runtime may be required to bridge the connectivity gap.

The SAP data model is more complex than Salesforce's. A Salesforce Account maps to SAP's Business Partner, which may have multiple roles (customer, vendor, employee) and complex address and relationship structures. The mapping work is not trivial — budget two to three weeks of dedicated analysis for the Account-to-Business Partner mapping before integration development begins.

Organisationally: SAP teams operate on different change control cycles to Salesforce teams. SAP changes may require six-week lead times; Salesforce changes can be deployed in days. Design integration APIs to be loosely coupled and versioned, so that Salesforce can evolve independently of SAP's release schedule.

Oracle-Specific Considerations

Oracle ERP Cloud (Fusion) exposes REST APIs that are generally well-suited to Salesforce integration. Oracle E-Business Suite (EBS), the older on-premise version, has a more complex API landscape — custom integrations often go through Oracle Integration Cloud (OIC), which is Oracle's iPaaS offering.

Oracle's data model for customers (Party, Account, Site) has its own complexity distinct from Salesforce's Account-Contact-Address model. The Oracle Trading Community Architecture (TCA) model is particularly intricate — customer relationships, site uses, and account hierarchies do not map directly to Salesforce. A detailed data model mapping document is essential before integration design begins.

Oracle Fusion is increasingly being positioned by Oracle as a CRM replacement in addition to ERP. Organisations with Oracle Fusion may face internal pressure to use Oracle's CRM capabilities rather than Salesforce. The integration architecture should be designed to be non-duplicative — if Salesforce is selected for CRM, Oracle's CRM modules should be turned off or limited to the capabilities that genuinely don't exist in Salesforce.