Integration Architecture: Connecting Sales Cloud V2 to S/4HANA Public Cloud

“How does the integration actually work?” It is the first question in almost every Sales Cloud V2 discovery call we run, and the right one to start with.

The short answer: SAP delivers pre-built integration content on SAP Integration Suite that connects SAP Sales Cloud V2 to S/4HANA Public Cloud for the flows that matter: master data replication, live pricing, quote-to-order and order status back into the CRM. You configure and deploy SAP’s packages rather than building connectors from scratch. Pre-built does not mean zero effort, though: mapping, data quality and operational setup still take real time.

This post covers the architecture from the ground up. For the broader view of running both systems as one stack, see our guide to the integrated S/4HANA Public Cloud and Sales Cloud V2 stack.

TL;DR: SAP provides standard iFlow packages on SAP Integration Suite for the Sales Cloud V2 and S/4HANA Public Cloud combination. Master data comes from S/4HANA (business partners, products, organisational data, pricing conditions). Prices can be simulated live in S/4HANA while a quote is created, and quotes turn into follow-up sales orders in S/4HANA. Custom logic belongs on SAP Business AI Platform (BAIP, formerly BTP) as side-by-side extensions. Data quality and error monitoring are the two most underestimated parts of the project.

How does Sales Cloud V2 connect to S/4HANA Public Cloud?

Both are SAP SaaS products, and the connector between them is SAP Integration Suite, specifically its Cloud Integration capability on SAP BAIP. Sales Cloud V2 exposes REST APIs; S/4HANA Public Cloud exposes released OData and SOAP APIs documented on the SAP Business Accelerator Hub. Integration Suite has to be provisioned on your BAIP subaccount before any iFlow can be deployed, a day-one infrastructure task that sometimes gets overlooked in early planning.

The connection is not direct system to system. Everything flows through Integration Suite, which handles retries, error queues, message monitoring and the mapping between two different data models. A point-to-point API call is technically possible, but then you own all of that operational work yourself.

The standard integration content

SAP publishes the content on the SAP Business Accelerator Hub in two packages:

• SAP Sales Cloud Version 2 Integration for Sales Processes with SAP S/4HANA Cloud Public Edition: follow-up quote in S/4HANA from an opportunity, follow-up sales order from a sales quote, simulation of quotes and orders for pricing, and sales order replication in both directions.
• SAP Sales Cloud and SAP Service Cloud Version 2 Integration for Master Data with SAP S/4HANA Cloud Public Edition: business partners and contact relationships, products, sales areas and other organisational data, pricing conditions, product stock and equipment.

Deployment means copying the package into your tenant, configuring connections and value mappings, and deploying the iFlows to your Cloud Integration runtime. SAP maintains these packages and ships updates, which is a real advantage over custom connectors, and one that disappears the moment you modify a standard iFlow instead of copying it first. SAP’s help page on integrating Sales Cloud V2 with S/4HANA Cloud Public Edition for simulation and transfer walks through the configuration.

On the S/4HANA side, communication arrangements define which APIs are exposed and to which technical users. On the Sales Cloud V2 side, communication systems and the outbound and inbound connections have to be set up to match. Getting both right is the prerequisite step most integration guides treat as a footnote; in practice it takes a sprint of setup and testing before the first iFlow goes live.

The service side of the same topology works with the same master data package but different documents; see the Service Cloud V2 integration with S/4HANA Public Cloud for cases, installed base and service orders.

Master data replication

S/4HANA is the system of record for customers, products and pricing; the CRM consumes them.

Business partners. The standard iFlows replicate business partners and contact relationships between S/4HANA and Sales Cloud V2, with confirmation messages in both directions. Changes are pushed when they happen, not collected in a nightly batch. The mapping handles the structural difference between S/4HANA’s business partner model and the account and contact model of Sales Cloud V2. Get it wrong and you will spend the first weeks after go-live merging duplicate accounts.

Products. Products replicate from S/4HANA into the Sales Cloud V2 product master, together with product groups, units of measure and sales areas. Reps quote products whose data originates in S/4HANA.

Organisational data. Sales organisations, distribution channels, divisions, sales offices and groups replicate as well. This is where the field mapping becomes demanding: your S/4HANA sales area structure has to line up with the territories and teams in the CRM.

Pricing and transactional flows

Live pricing. The most useful flow for sales is often the simulation. While a rep builds a quote, Sales Cloud V2 can call S/4HANA to simulate the quote or order and return the price, including customer-specific conditions and scales. SAP also offers replication of pricing conditions into the CRM; which of the two you use is an architecture decision, and our quote-to-cash post explains why we prefer one price truth in the ERP.

Quote to order. When the customer accepts, the sales quote in Sales Cloud V2 creates a follow-up sales order in S/4HANA through the standard iFlow. Sales orders replicate back into the CRM, so account managers see the order and its status without logging into the ERP.

Financial context. For invoices, credit exposure and sales contracts, SAP’s Customer Insights integration package retrieves the data from S/4HANA in real time and shows it in the account view. For B2B sales teams where credit exposure affects sales decisions, that removes the call to finance.

In practice the transactional flows are rarely the technical bottleneck. Data mapping and organisational alignment take more time than the plumbing. At intelligentfood, Sales & Service Cloud V2 went live in three months, connected to its ERP.

Where custom logic lives: BAIP side-by-side

The clean-core principle applies to integration as much as to extensions. Standard iFlows handle the documented scenarios. Anything specific to your business model, your approval process or your validation rules lives outside both systems as a side-by-side extension on SAP BAIP.

Custom logic inside an iFlow mapping is a trap: it works in the short term and becomes unmaintainable the moment SAP ships an update you need to re-apply your changes to.

Integration Suite, events and SAP Build

SAP Integration Suite is the runtime for your iFlows and the place where you inspect every message that passed, failed or was retried. Monitoring dashboards and alert rules at go-live are not optional; without them, failures stay invisible until a rep notices that a quote is missing data.

Events instead of polling. S/4HANA publishes business events, and SAP’s eventing services on BAIP deliver them to subscribers. Instead of a job that checks for changes every 15 minutes, the extension reacts when something changes. For high-volume scenarios this reduces latency and unnecessary load.

SAP Build Process Automation handles approval orchestration. If a quote needs a manager’s approval before it becomes an order, or a credit check gate before submission to S/4HANA, that workflow runs in SAP Build rather than inside Sales Cloud V2 or S/4HANA: side by side and independently deployable.

For more depth on building extensions without touching the core, our clean core with SAP CAP guide covers the extension model.

Common pitfalls and how to avoid them

Almost every integration project we have seen has at least one of these.

Assuming “SAP integrated” means “works out of the box”. The standard content is a starting point. You still configure connections, define mappings for your data model, clean the master data and test every flow end to end. Budget integration design and configuration as a proper workstream, not a two-day task.

Modifying iFlows in place. The most common technical mistake. Copy the standard iFlow before you touch it, make changes in the copy, document every delta. It takes an hour up front and saves days when SAP ships the next update.

Skipping monitoring setup. Integration Suite has built-in message monitoring, but many teams deploy iFlows without alert rules. Failed messages then sit in the queue for days. Set up alerts for every iFlow at go-live, assign an owner and write a runbook, so a failed product or business partner update is fixed the same day.

Underestimating data quality and mapping. S/4HANA and Sales Cloud V2 have different data models; business partner structures, account hierarchies and product classifications do not map trivially. In our experience, mapping design and data cleansing take as long as the iFlow configuration, sometimes longer. Duplicate customers or products without sales area assignments surface the moment replication starts, so fix them in the source system before go-live.

If S/4HANA Public Cloud is still ahead of you, the S/4HANA readiness assessment settles data and scope questions before the integration design starts. And if you are choosing who should build both halves, our guide to the best SAP partner for Cloud ERP and CRM in Switzerland explains why one team for both sides pays off at exactly these seams.

---

Questions about your specific integration scenario? Whether you are starting a new Sales Cloud V2 rollout or untangling an existing integration, talk to our team.