Integrating Salesforce with SAP S/4HANA

That works until it does not. A price changes in SAP and a quote goes out at the old one. An account is created twice and the credit check runs against the wrong record. An order is confirmed in Salesforce that fulfilment cannot deliver.

None of this is a technology problem. It is a question of which system is allowed to be right, and how quickly the other one finds out.

What actually has to agree

Before anyone chooses a platform or writes an interface, it is worth being specific about what is being synchronised. In an order-to-cash landscape it usually comes down to six things.

• Customer and business partner records. The same organisation exists in both systems, usually with different identifiers, sometimes with different addresses and almost always with different ideas about who owns the relationship.
• Products and materials. SAP holds the material master. Salesforce holds a version of it that sales can quote from. Every divergence between the two turns into a quote that cannot be fulfilled.
• Pricing conditions. The most common source of friction, because pricing in SAP is rarely a single number. It is a structure of conditions, scales and discounts that does not map cleanly onto a CRM price book.
• Sales orders. Created in the CRM, executed in the ERP. This is the flow everyone thinks of first and it is rarely the hardest one.
• Order status and fulfilment. The return leg. Sales needs to know what shipped, what is backordered and what was invoiced, without logging into SAP.
• Credit and availability. Whether this customer can order, and whether the stock exists. Both live in SAP and both are needed at the moment of quoting.

The decisions that matter more than the technology

Integration projects tend to start with a platform choice. They tend to get into trouble over four decisions that have nothing to do with platforms.

1. Which system is the source of truth, per object

Not per system, per object. Materials and pricing almost always originate in SAP. Opportunities and activity almost always originate in Salesforce. Customers are genuinely contested, and the answer differs by organisation depending on whether finance or sales creates the account.

Leaving this vague is the single most reliable way to end up with two systems that disagree and no rule for resolving it.

2. What real time actually needs to mean

Not everything needs to be instant. A material master change can wait an hour. A credit block cannot wait at all. Treating every object as real-time is expensive; treating none of them as real-time is why sales quotes from stale data.

The useful exercise is to go object by object and ask what the business cost is of the data being an hour old. Most of the list turns out to tolerate latency perfectly well.

3. What happens when a message fails

Every integration fails sometimes. The question is whether anyone finds out. A sync that silently drops a sales order is worse than no sync at all, because the business has stopped checking manually.

Error handling, alerting and a way to replay failed messages are not a phase-two concern. They are the difference between an integration people trust and one they work around.

4. Who owns it after go-live

Custom interfaces need maintenance every time either platform changes, and Salesforce releases three times a year. If the answer to who maintains this is the person who built it, the integration has a shelf life measured by that person's tenure.

Where these projects get into trouble

Two data models that were never meant to meet. SAP's structures are built around financial and logistical integrity. Salesforce's are built around the sales conversation. Neither is wrong; they just do not line up, and the mapping between them is where most of the effort goes.

The cases nobody designed for. Partial deliveries. Pricing exceptions agreed on a call. A customer that exists in one system and not the other. These surface in month four of a build, after the budget is set.

Volume. An integration that works for a thousand messages a day may not work for a hundred thousand. This is worth establishing before the architecture is fixed rather than after.

Scope creep through the back door. The first integration is customers and orders. Then someone asks for contracts, then service cases, then a second Salesforce org from an acquisition. An architecture that assumed one flow rarely survives that.

Build it, or start from prebuilt content

There are three realistic routes, and the honest answer is that all three are appropriate in different situations.

Point-to-point. Fastest to get one interface live. Becomes unmanageable somewhere around the fifth or sixth, because each connection is maintained independently and nobody has the whole picture.

Custom development on an integration platform. Full control, and the right answer when the process genuinely is unusual. The cost is that the build effort and the ongoing maintenance are both yours, and the edge cases are all discovered the hard way.

Prebuilt integration content. The standard order-to-cash scenarios already exist and are deployed as a baseline, leaving configuration rather than development. Salesforce Integration Content for SAP S/4HANA runs on SAP Integration Suite and covers customer, product, pricing and sales order flows out of the box.

The trade-off is straightforward. Custom gives you exactly what you specify, at the cost of specifying and maintaining all of it. Prebuilt content gives you most of it immediately, and the work shifts to the part that is genuinely specific to your landscape: your sales organisation structure, your pricing logic, your approval rules.

Most organisations discover that the genuinely unusual part of their integration is a good deal smaller than they assumed at the outset.

A note on event-driven synchronisation

Batch integration made sense when the alternative was expensive. It is now the more expensive option in most landscapes, because the cost has moved from infrastructure to the consequences of stale data.

Event-driven patterns, where a change in one system publishes an event the other subscribes to, remove the window in which the two systems disagree. Salesforce's Pub/Sub API and SAP's event-driven standards both support this, and Rojo's Salesforce integration content is built on them rather than on the older polling-based streaming approach.

Worth knowing: integrations built on Salesforce's legacy CometD-based streaming options, PushTopic events and Generic events, are running on components Salesforce classifies as legacy and no longer enhances. There is no published retirement date, but anything built on them will need reworking eventually.

Where to start

Two questions answer most of the scoping.

Which objects, in which direction, and how fresh do they need to be? Six rows on a whiteboard settles more than a month of architecture discussion.

Is any of this genuinely unique to us? Where the answer is no, and for order-to-cash it usually is no, prebuilt content removes the work. Where the answer is yes, that is where the effort belongs.

If you are weighing a build against prebuilt integration content for Salesforce and SAP S/4HANA, the practical next step is to map the objects first. The platform decision follows from it rather than the other way round.