Hey friends,
Salesforce SAP integration usually mixes three patterns: read SAP data live in Salesforce with Salesforce Connect over OData, replicate master data such as customers and products through middleware on a schedule or on events, and send Salesforce events, like a closed-won opportunity, to SAP through an integration platform. You choose by asking which system owns the data and whether a change has to arrive now. SAP also has to expose the data first, through OData, IDoc, RFC or its S/4HANA Cloud APIs.
This guide follows Salesforce's Integration Patterns guide and External Objects reference, plus SAP's own SAP Integration Suite documentation, its Salesforce adapter installation guide and MuleSoft's SAP connector docs, as I read them on October 28, 2026. SAP product names change over time, so I use the names the SAP pages use today. For the general decision framework, start with Salesforce Data Integration.
A few terms first. ERP is enterprise resource planning software, the kind of software that runs business processes such as orders and finance, and SAP makes it. OData is a standard web protocol for reading and changing data. IDoc (Intermediate Document) is the message format SAP systems use to exchange business documents. RFC (Remote Function Call) is SAP's standard interface for integrating ABAP systems with other systems. Middleware is software that sits between systems and moves, transforms and routes data.
Which Salesforce SAP integration pattern do you need?
Salesforce's guide sorts integrations by what you need, not by product. Here is how that maps to SAP projects.
| You need to | Pattern in the guide | Usual SAP project example |
|---|---|---|
| Show SAP data in Salesforce without storing it | Data Virtualization | A service rep sees open orders from the ERP on the account page |
| Keep records in both systems in sync | Batch Data Synchronization | Customers and products created in SAP show up in Salesforce overnight |
| Start a process in SAP when something happens in Salesforce, and nobody waits | Remote Process Invocation, Fire and Forget | A closed-won opportunity creates a sales order in SAP |
| Ask SAP a question and use the answer right away | Remote Process Invocation, Request and Reply | A rep checks a delivery date before promising it |
| Let SAP create or update Salesforce records | Remote Call-In | SAP writes the order status back to the opportunity |
Each pattern is explained in Salesforce Integration Patterns. What changes with SAP is the other end of the wire, so that's the next question.
How SAP exposes its data
Salesforce can only talk to what SAP publishes. SAP's own documentation describes several doors, and which one you get depends on the SAP system you run.
- OData APIs on SAP S/4HANA Cloud. SAP's training lesson on communication management says that to consume SAP S/4HANA Cloud OData APIs and integrate with other systems, an administrator sets up a communication user, a communication system and a communication arrangement. The arrangement defines which system and user can call which APIs, and every arrangement must be based on a communication scenario. SAP's example is Purchase Order Integration (
SAP_COM_0053). - OData Provisioning for SAP Business Suite. SAP Integration Suite has a capability called OData Provisioning that, per SAP, helps you explore SAP Gateway services from SAP Business Suite systems and publish them as OData endpoints, without an on-premises SAP Gateway server.
- IDoc and RFC. SAP Integration Suite's out-of-the-box adapters include an IDoc adapter, which exchanges IDoc messages with systems that support communication through SOAP web services. The RFC receiver adapter is described by SAP as the standard interface for integrating on-premise ABAP systems with cloud systems using SAP Cloud Connector, and it supports SAP NetWeaver 7.31 or higher.
- BAPIs, RFC and IDocs through a connector. MuleSoft's SAP connector uses SAP's Java Connector libraries to run BAPI functions over RFC, and to send and receive IDocs. It targets SAP systems based on SAP NetWeaver.
If you can't say which of these your SAP team will open up, stop and ask before you design anything. That one answer decides the toolset.
Salesforce SAP integration tools compared
| Tool | Best for, the SAP side it uses, and what to watch out for |
|---|---|
| Salesforce Connect with an OData adapter | Best for: Showing SAP data in Salesforce live, no copy. SAP side: SAP data exposed by an OData producer. Watch out for: Some features aren't available for external objects. |
| SAP Integration Suite (Cloud Integration) with the Salesforce adapters | Best for: Integration flows owned by the SAP team, in both directions. SAP side: OData, IDoc, RFC and other SAP adapters. Watch out for: SAP's guide says there is no manual install on Cloud Foundry. |
| MuleSoft with the SAP connector | Best for: Integration flows owned by the Salesforce side or a central API team. SAP side: BAPI and RFC calls, IDocs. Watch out for: MuleSoft says the SAP connector needs a separate license. |
| Apex or Flow callouts to SAP APIs | Best for: A small number of real-time calls. SAP side: Whatever HTTP API SAP exposes. Watch out for: Salesforce says calls made from trigger context must execute asynchronously. |
| Data Loader or a similar import tool | Best for: A one-time migration. SAP side: A file export. Watch out for: Not a base for ongoing integration. |
Show SAP data in Salesforce with Salesforce Connect
This is the Data Virtualization pattern, and Salesforce's guide names SAP as an example: it says to use Salesforce Connect to pull data from systems such as SAP, Microsoft and Oracle in real time, without making a copy. The OData adapter connects to data exposed by any OData producer, and Salesforce says it supports OData versions 4.01, 4.0 and 2.0. Salesforce maps each table to an external object, whose API name ends in __x.
Why do this? Salesforce's guide lists the benefits: no data storage used in Salesforce, no regular sync to worry about, a declarative setup, and global search that can search the connected system. It also gives an example close to home. A manufacturing company wants its service agents to see real-time order information from the back-office ERP without learning to run ERP reports.
A few Salesforce details save pain later:
- Relationships need a key. SAP rows don't carry Salesforce's 18-character record IDs, so external objects have two special lookups. Use an external lookup (matches on the External ID standard field) or an indirect lookup (matches on a custom field marked External ID and Unique).
- Plan for slow or large responses. Salesforce has a configurable 120-second maximum wait for the external system. With server-driven paging, each page can't exceed 2,000 rows.
- Know the rate-limit option. If you hit rate limits on external objects, the guide suggests the High Data Volume option on the external data source, which bypasses most rate limits but has its own limitations.
- Check what isn't supported. The guide says external objects behave like custom objects, but some features aren't available for them. It also has a separate section of reporting considerations, so read it before you promise reports on SAP data.
Use Salesforce Connect for looking at SAP data. Salesforce says this pattern is used primarily for small-volume, real-time activities.
Replicate SAP master data with middleware
When Salesforce needs its own copy of customers, products or prices, you're in the Batch Data Synchronization pattern. Salesforce's guide rates replication through a third-party ETL (extract, transform, load) tool that can run change data capture as Best when an external system needs to send a large amount of data into Salesforce. Salesforce Bulk API covers the Salesforce end.
You have two common routes.
- SAP Integration Suite. SAP's feature scope description, dated September 22, 2026, lists a Salesforce sender adapter and a Salesforce receiver adapter among the out-of-the-box adapters. It also lists a Salesforce Pub/Sub sender adapter that consumes messages from Salesforce Pub/Sub API and a receiver adapter that publishes to it. SAP's installation guide (version 1.2.0, April 2026) covers registering an application in Salesforce, which connects the adapter through an OAuth 2.0 app. For Cloud Foundry it says there is no manual way to install the adapter: you import it into an integration flow or copy the package from the Discover workspace to the Design workspace, then deploy it.
- MuleSoft. MuleSoft documents Anypoint Exchange templates for Salesforce and SAP, including Account Customer Bidirectional Sync and Product Bidirectional Sync, plus one-way ones such as Customer Migration (SAP to Salesforce) and Opportunity Broadcast (Salesforce to SAP). They are starting points, not finished projects. For the broader comparison, see MuleSoft vs Salesforce.
Whichever tool you pick, the Salesforce side looks the same. Add an external ID field to the object, store the SAP key in it (for example the customer number), and upsert on it so reruns don't create duplicates. Salesforce Data Integration shows the REST call and the 201, 200 and 300 outcomes.
Send Salesforce events to SAP
For "something happened in Salesforce, tell SAP", the guide's Fire and Forget pattern rates flow-driven platform events as Best when the remote process starts from an insert or update, and calls Pub/Sub API the recommended way for external consumers to consume events. It rates Change Data Capture as Best too. SAP Integration Suite's Salesforce Pub/Sub sender adapter is the SAP-side listener for that. The guide also says Salesforce publishes an event once and doesn't retry, so it is up to the subscriber to request a replay, and that the event bus lets you replay high-volume platform events for 72 hours. For the mechanics, see Salesforce Platform Events.
On the SAP side, SAP's Integration Suite includes Event Mesh and advanced event mesh for publishing and consuming business events. That matters if SAP should tell Salesforce about changes without Salesforce polling.
Cert Lab by Nick Frates
Let the Platform Integration Architect Cert Lab test you to success
Scenario questions on integration patterns, callouts, platform events and API choice for all six Platform Integration Architect sections, with every option explained.
Start the Platform Integration Architect Cert Lab for $9.99 →Not ready to buy? Try a free lesson and see how fast you learn.
A worked example: order to cash
Here's a made-up but typical setup. SAP owns customers, products and orders. Salesforce owns leads, opportunities and the sales conversation.
| Need | Approach | Why |
|---|---|---|
| Customers and products from SAP appear in Salesforce overnight | Middleware (SAP Integration Suite or MuleSoft) upserting on an SAP customer number field | Scheduled, one-way, and SAP is the master |
| A closed-won opportunity creates a sales order in SAP | Flow publishes a platform event, middleware subscribes through Pub/Sub API and calls SAP | Asynchronous, so nobody waits for SAP |
| SAP sends the order number back | Middleware updates the Salesforce opportunity through the API | A remote system calling in, one record at a time |
| A rep checks open invoices on the account page | Salesforce Connect external object over OData | Live data you don't want to store |
| Finance loads 20,000 legacy accounts once | Data Loader | A one-off, not an integration |
Pitfalls to avoid
- Starting with the tool instead of SAP's exposure options. Salesforce Connect needs an OData producer, and S/4HANA Cloud APIs need a communication arrangement. Find out what SAP can offer first.
- Treating Salesforce Connect as a data store. It fetches data on demand. Salesforce waits up to 120 seconds for the external system and pages the results, so it fits small, real-time lookups.
- Leaving the system of record undecided. The guide says data integration needs mastering, governance and de-duplication. Decide whether SAP or Salesforce owns each field before you map anything.
- Forgetting the shared key. Without the SAP key stored in Salesforce, every rerun risks duplicates. Use an external ID and upsert.
- Putting multi-system transactions in Salesforce. The guide says Salesforce can't take part in distributed transactions, so rollback and compensation logic belongs in the middleware layer.
- Ignoring Salesforce API limits. Per Salesforce, calls from Bulk API, Bulk API 2.0 and installed managed packages count against the org's daily allocation. Size your sync before go-live.
- Testing against production. SAP's installation guide uses test.salesforce.com as the login URL for a Salesforce sandbox. Connect a sandbox and an SAP test system first.
- Assuming product names stay put. SAP renames capabilities. Use the names in SAP Help when you write specs, and re-check them before a project starts.
Cert Lab by Nick Frates
Practice the integration scenarios
Lessons, flashcards, a quiz for each of the six exam sections and full practice exams, every answer explained.
Start the Platform Integration Architect Cert Lab for $9.99 →Not ready to buy? Try a free lesson and see how fast you learn.
If you're building these skills for a certification, my Platform Integration Architect study guide lists every exam objective, and Salesforce API Types helps you choose between the APIs. For moving data once, read Salesforce Data Migration and Salesforce Data Loader. And the Platform Integration Architect Cert Lab I built is where I'd practice scenarios like these.
FAQ
How do you integrate Salesforce with SAP?
You pick a pattern: Salesforce Connect over OData for live reads, middleware for replicating data, or Pub/Sub API events for pushing changes to SAP. SAP has to expose the data first, through OData, IDoc, RFC or its S/4HANA Cloud APIs.
Does Salesforce have a native SAP connector?
Salesforce Connect has OData adapters that Salesforce says can pull data from systems such as SAP, as long as the data is exposed by an OData producer. Other approaches use SAP Integration Suite, MuleSoft or custom callouts.
What does SAP offer for connecting to Salesforce?
SAP's feature scope description lists Salesforce sender and receiver adapters in SAP Integration Suite, plus Salesforce Pub/Sub API sender and receiver adapters.
Can MuleSoft connect Salesforce to SAP?
Yes. MuleSoft has an SAP connector for SAP NetWeaver-based systems that works with BAPI functions over RFC and with IDocs, and it needs a separate license.
What is an IDoc?
It's an Intermediate Document, the message format SAP systems use to exchange business documents. SAP Integration Suite and MuleSoft both have ways to send and receive them.
Should I copy SAP data into Salesforce or read it live?
Copy it if Salesforce processes, reports on or automates against it. Read it live with Salesforce Connect if users only need to see a small amount of current data.
How do I avoid duplicates when syncing SAP and Salesforce?
Store the SAP key, such as the customer number, in a Salesforce external ID field and upsert on it, so a rerun updates instead of inserting.
Hope this helps!
Best,
Nick
