Salesforce and SAP Integration Patterns for Manufacturers

Short answer: almost every Salesforce and SAP integration in manufacturing reduces to four patterns: batch synchronization, request and reply, data virtualization, and event streaming. Pick one per data object, and pick on two questions only: which system owns the record, and how stale a copy is allowed to be. The middleware follows from those answers, not the other way round.

We have made this call on order, product and service data for asset-heavy manufacturers. Projects rarely fail because somebody picked the wrong iPaaS. They fail because nobody wrote down who owns the record.

What is a Salesforce and SAP integration pattern?

An integration pattern is the shape of a data flow, independent of the tool that carries it. Salesforce's own architecture guidance names a small set: batch data synchronization, remote process invocation (request and reply, or fire and forget), remote call-in, UI update based on data changes, and data virtualization. Every connector and iPaaS on the market is one of those patterns with a logo on it. Choosing the pattern is architecture. Choosing the product is procurement.

Which SAP data actually has to move for a manufacturer?

Three families cover most of it, and they do not want the same treatment.

• Order data. Quotes and opportunities start in Salesforce, but SAP owns the order the moment it is confirmed. Sales needs the confirmed quantity, promised date and status back.
• Product, pricing and inventory data. SAP owns the material master, condition records and stock. Salesforce is a consumer here, never an author.
• Service and asset data. Ownership genuinely splits. SAP holds serial numbers, bills of material and warranty terms; Salesforce holds the case, the entitlement and the field visit.

Write the owner next to each object before you evaluate a tool. If two systems can write the same field, you have not designed an integration. You have designed a conflict with a schedule.

What are the four patterns worth considering?

Batch synchronization

A scheduled bulk transfer, usually nightly. Right for material master, cost data and historical actuals. Cheap, easy to reason about, easy to replay after a failure. The price is staleness measured in hours, and a nightly window that tightens as volume grows.

Request and reply

Salesforce calls SAP and waits: availability check, credit check, price simulation, order submission. Right when the user needs the truth at that exact second and a cached copy would be worse than a short spinner. The price is that SAP availability becomes CRM availability.

Data virtualization

Salesforce Connect exposes SAP data as external objects over OData 2.0 or 4.0, typically through an SAP gateway, so records are read live and never stored in Salesforce. Right for long-tail reference data people look up but nobody reports on: historical invoices, delivery documents, closed service orders. The price is weak reporting, weak automation and nothing offline.

Event streaming

SAP publishes a change and Salesforce reacts: delivery confirmed, batch released, shipment blocked, asset commissioned. Right for state changes where minutes matter and volume is too high to poll. The price is that you now own ordering, retries and duplicate handling.

How do you choose? Data ownership and latency, not middleware brand

1. Name the owner per object. One writer, everyone else reads. Put it in the design document, not in someone's head.
2. Set a latency budget in plain language. "A rep must never promise a date the plant cannot meet" is a budget. "Real time" is a wish.
3. Count the volume honestly. Peaks, not averages. An event pattern that is comfortable at a thousand messages a day behaves differently at a million a week.
4. Decide the failure behaviour first. What does a rep see when SAP is down during the quarterly close? Silence is the worst possible answer.

Run those four and the pattern usually picks itself. Most manufacturers end up hybrid: batch for master data, events for order and delivery status, request and reply for the two or three checks that must be live, virtualization for the archive nobody wants to copy.

Where do manufacturers get this wrong?

• Syncing everything. Every field copied is a field to reconcile forever. Copy what a Salesforce process actually acts on.
• No stable ID map. Matching on customer name or material description works in the demo and fails in production. Carry the SAP key as an external ID.
• Order posting that is not idempotent. A retry that creates a second order in SAP is the most expensive bug in this category. Every write needs a correlation key.
• No reconciliation job. Drift is a certainty, not a risk. Something has to count both sides and report the delta.
• Buying middleware first. The tool then dictates the architecture, which inherits whatever that tool happens to be good at.

Does the middleware brand matter at all?

It matters, second. Salesforce ships MuleSoft Direct integrations for Manufacturing Cloud that keep customer, product and sales order data in sync with SAP. Data 360 offers an SAP HANA connector where batch ingestion is generally available and zero copy federation is still in beta, worth knowing before you plan an analytics layer around it. SAP Integration Suite, Boomi and direct API work remain valid. Each is a pattern in packaged form. Pick the pattern first, then the product that implements it with the least custom code.

The payoff is operational. On a connected-asset programme for ASSA ABLOY we took weekly cases from 3,000 to 350, a 93% reduction across 11,000 devices and up to 2.5 million events per week, with no added support staff. Event volume was routed by pattern, not pushed through one generic sync. Tekunda integrates Salesforce across 70+ enterprise systems, SAP included, as a certified Salesforce SI, ISV and PDO.

FAQ

Should Salesforce or SAP own the sales order?

SAP, from confirmation onward. Salesforce should own the quote and the opportunity and then read order status back, so there is exactly one place where a confirmed order lives.

Is real time integration always better?

No. Real time raises cost, coupling and failure surface. Use it only where a stale value would cause a wrong commitment to a customer, and use batch everywhere else.

Do we need MuleSoft to integrate Salesforce and SAP?

No. MuleSoft is a strong fit for API-led programmes with many consumers, but the same patterns run on SAP Integration Suite, other iPaaS platforms or direct API work.

How long does a Salesforce and SAP integration take?

It depends far more on how many objects you sync than on the tooling. Two or three well-owned objects can go live in weeks; an undecided ownership model can stall a project for a year.