Salesforce–SAP integration: the five decisions that decide whether it holds

A Salesforce–SAP integration succeeds when five decisions are made explicitly before any build: which system owns each business object, whether each flow is real-time or batch, what sits in the middle, how failures are surfaced and replayed, and who owns the integration after go-live. Teams that skip these decisions end up with a working connector and an untrustworthy quote-to-cash process.

Salesforce is where the customer relationship lives. SAP is where the order, the invoice and the stock live. The business needs one quote-to-cash process across both. The integration is the seam, and seams are where enterprise software tears.

Decision 1: Which system owns each object?

Every shared object needs exactly one system of record. Two masters for the same field guarantee drift. Agree the ownership of each object with sales operations and finance before an engineer writes a line of mapping. A typical split looks like this:

• Account and customer master: owned by SAP, which holds credit, tax and payment terms, and flows to Salesforce. Common mistake: letting sales create SAP customers without credit checks.
• Contact: owned by Salesforce; only billing contacts flow to SAP. Common mistake: syncing every contact into SAP.
• Product and price list: owned by SAP and flowed to Salesforce or CPQ. Common mistake: maintaining prices in both systems.
• Quote and opportunity: owned by Salesforce and kept there. Common mistake: pushing draft quotes into SAP.
• Sales order: owned by SAP, with status flowing back to Salesforce. Common mistake: allowing order edits in both systems.
• Invoice, payment and credit status: owned by SAP, shown read-only in Salesforce. Common mistake: hiding finance status from account managers.
• Inventory and available-to-promise: owned by SAP, queried from Salesforce on request. Common mistake: copying full stock tables nightly.

Decision 2: Real-time, near-real-time or batch?

Not every flow deserves an API call. Over-using real-time integration creates fragile coupling; over-using batch creates stale data that sales stops trusting.

• Real-time, synchronous API: price and availability checks during quoting, and credit checks before order submission. The user is waiting.
• Near-real-time events: order status, shipment and invoice updates flowing back to Salesforce within minutes.
• Batch: customer master clean-up, historical sales data for analytics, and large product catalogue refreshes.

A useful rule: if a salesperson is waiting on screen, use an API; if they just need to know soon, use an event; if nobody is waiting, batch it.

Decision 3: What sits in the middle?

Point-to-point connections are quick to build and expensive to own. Once a third system joins, such as billing, e-commerce or a data platform, the number of interfaces grows faster than the team can maintain. Most enterprises are better served by an integration layer: SAP Integration Suite, MuleSoft, Boomi, Azure Integration Services or a well-governed custom API layer.

The choice is less about features than about who will run it. Pick the platform your team can operate at 3 a.m., and keep the business logic in the systems of record, not buried in middleware mappings.

Decision 4: How are failures surfaced and replayed?

Every integration fails sometimes: a locked SAP record, an expired token, a malformed address. The question is whether anyone finds out before the customer does.

• Make every message idempotent, so it can be safely replayed.
• Send failures to a visible queue with an owner, not to a log file.
• Show integration status on the Salesforce record, so sales is not guessing whether an order went through.
• Reconcile daily: counts and totals of orders, invoices and customers in both systems.

Decision 5: Who owns it after go-live?

Integrations fail organisationally more often than technically. The Salesforce team assumes SAP owns it; the SAP team assumes the CRM team does. Name one owner, give them an operational dashboard and a change process, and include integration impact in every Salesforce release and every SAP transport review.

A sequencing that works

• Agree the system-of-record decisions and sign them off with sales operations and finance.
• Build customer and product master sync first; everything else depends on them.
• Add real-time price, availability and credit checks for quoting.
• Add order creation and the status flow back to Salesforce.
• Add invoice and payment visibility for account managers.
• Add reconciliation, alerting and the run book before calling it done.

How Webneuron helps

We design and build Salesforce and SAP integrations behind a governed API layer, with the system-of-record decisions agreed before the build begins. Our Salesforce and SAP integration playbooks cover the detail, and a discovery call is the quickest way to test your own landscape against these five decisions.

Frequently asked questions

What is the best way to integrate Salesforce with SAP? Through an integration layer rather than point-to-point code, with one system of record per object and a mix of real-time, event and batch flows.

Should customer master data live in Salesforce or SAP? Usually SAP, because credit, tax and payment terms live there. Salesforce holds the relationship and contacts, and receives the customer master.

How long does a Salesforce–SAP integration take? A focused quote-to-cash integration often takes three to six months, depending on data quality, middleware readiness and the number of flows.

Do we need middleware for Salesforce–SAP integration? For two systems and a few flows, not always. Once a third system is involved, or volumes grow, an integration layer is cheaper to own.