Salesforce-SAP integration: data ownership and failures

A Salesforce-SAP integration should support a defined business handover, such as moving an approved sales opportunity into order processing or returning ERP status to customer service. Synchronising every available field usually adds maintenance work. Decision-makers first need an inventory of objects, their owners and the consequences of incorrect data. This provides a basis for deciding whether existing integration products are sufficient or custom middleware is needed.

Starting point and project boundaries

• Define the transition from the Salesforce sales workflow to SAP: leads, accounts, quotations and orders carry different business commitments.
• Clarify whether customers exist across multiple legal entities and which external identifier connects records between the systems.
• Identify the duplicate entry work that will disappear and the information that still requires confirmation by a business owner.

Assign a system of record to each object. Define stable identifiers, duplicate handling, required fields and changes originating on both sides. Polling, events and scheduled reconciliation are possible building blocks; the right combination depends on interfaces, volumes and acceptable delays. Distinguish technical delivery from business processing. A successful HTTP response does not prove that the target system created a valid order.

• Assign ownership per field.

Unrestricted bidirectional synchronisation can cause the two systems to overwrite each other's changes.

• Treat status transitions as business events with documented prerequisites; a field update alone need not trigger an order.
• Plan for limits, batching, backlogs and replay.

The acceptable delay between sales and ERP belongs in the integration contract.

Consider an illustrative workflow: Salesforce sends an approved order, SAP validates master data and returns an order number. Missing mappings place the transaction in a visible exception queue. After correction, it can be processed again in a controlled way. Repeating the same message must not create a second order. This example explains a design approach rather than claiming an existing customer implementation.

Practical acceptance scenarios for the first release

• Two Salesforce accounts refer to the same SAP customer. The integration flags the conflict instead of creating an unchecked duplicate customer.
• An opportunity is saved again after handover. Processing recognises the business action that has already been transmitted.
• SAP rejects an order because required information is missing. Salesforce exposes an actionable status and identifies the responsible team.

Acceptance testing should include duplicate messages, modified master data, expired credentials and extended outages. Separate ownership of business exceptions from technical incidents. An integration view should show which record was transferred, when and with which version.

A useful acceptance test follows an order from CRM submission to ERP confirmation. Include more than the successful path: send the transaction twice, change a customer mapping and interrupt the connection before confirmation. Agree who corrects a rejected order and how long unconfirmed transactions may remain pending. These cases define the integration scope more precisely than a list of fields to synchronise.

Before implementation, decide which system owns each business field. A conflict between a sales update and an ERP correction needs an explicit resolution rule. Verify that rule using a concrete record and require a restart without duplicates when the connection fails during a transfer. Include that failure case in the handover documentation.

A checklist for commissioning the work

• Request a field matrix covering direction, authoritative system, transformation and handling of empty or conflicting values.
• Distinguish a business cancellation from a technical retry so that corrections do not appear as additional business transactions.
• Check whether contract tests between the systems protect the workflow when either data model changes.

For a comparable proposal

• Provide Salesforce objects, SAP endpoints and business matching keys.
• Agree field-level ownership and handling of concurrent changes.
• Test duplicates, partial failures and reprocessing while reconciling both systems.

A technically sound interface cannot compensate for missing master-data rules. One complete workflow with clear owners and acceptance conditions creates a stronger foundation than a broad field synchronisation without agreed outcomes. Additional objects and business units can then be added deliberately.

Assess the benefit and control further expansion

• Measure the time until usable order information is available and the number of conflicts that sales and order processing must resolve manually.
• Expand to further objects once identity mapping and exception handling for the initial process are demonstrably traceable.
• Compare a standard connector with custom middleware using the same exception scenarios and operational-control requirements.

Identify the authoritative Salesforce record and its SAP counterpart. GSWE uses them to scope field mapping, synchronisation direction and failure handling for the first integration engagement.

Commission Salesforce SAP integration: Connect Salesforce to SAP via API.