Connecting SAP Sales Cloud V2 with Business Data Cloud: Integration Patterns That Work

We implement SAP Sales Cloud V2 and SAP S/4HANA Public Cloud with one team, and for a long time the analytics conversation around the CRM ended in one of two places: export to a warehouse someone maintains, or live with the embedded dashboards. SAP Business Data Cloud (BDC) opens a third route. This post collects the design patterns we apply when Sales Cloud V2 data has to meet ERP data in BDC, and the mistakes we steer clients away from.

TL;DR: Consume SAP data products wherever they exist, and check the catalogue for your release before building anything. Where Sales Cloud V2 data is not yet available as a data product, load it once into Datasphere and govern it as your own data product. Make pipeline-to-cash the first model, align three join keys early, keep real-time needs in the application integration, and let every consumer read one semantic model.

What BDC gives you to work with

SAP announced Business Data Cloud in February 2025. It brings SAP Datasphere, SAP Analytics Cloud, SAP Business Warehouse and SAP Databricks together in one managed offering (SAP Learning: Introducing SAP Business Data Cloud). The central building block is the data product, which SAP describes as “a refined data set, metadata describing the data set, and an access port or API” (SAP News, October 2025). On top of the data products SAP builds intelligent applications (earlier called insight apps); a Revenue Intelligence application was in restricted preview as of October 2025.

For a CRM architect this means two things. First, some of the data you need arrives modelled and maintained by SAP. Second, the rest still has to be brought in and modelled, and the quality of that work decides whether the platform pays off. How SAP-managed data products are activated and consumed is documented in SAP Help.

The patterns at a glance

Pattern	Use it for	Avoid it for
1. Data products first	Standard entities SAP already ships for your release	Rebuilding data SAP maintains for you
2. Pipeline-to-cash as first model	Sales and finance disagreeing about numbers	Starting with five domains at once
3. Real-time stays in the application layer	Quoting, availability, pricing at the point of sale	Dashboards that need live data “just in case”
4. One semantic model, many consumers	SAC stories, Databricks notebooks, Joule	Team-specific copies of “revenue”

Pattern 1: data products first, your own data product second

The reflex from a decade of CRM analytics is to build an extraction pipeline. Start one step earlier: open the data-product catalogue for your release and check which entities SAP delivers. The examples SAP named at launch were S/4HANA, SAP Ariba and SuccessFactors data, so do not assume that every Sales Cloud V2 object is already there. Every extractor you build next to an existing data product is a liability with your name on it: it breaks when an API changes, and it reintroduces the question “which opportunity amount is that?”

Where no SAP data product exists for the CRM entities you need (accounts, opportunities, activities), bring them in once, deliberately:

• Load path: the Sales Cloud V2 APIs or a replication flow into SAP Datasphere, one space for CRM data, no side copies.
• Treat it as a product: one owner, a documented definition per measure, a refresh schedule the business has agreed to.
• Plan the exit: when SAP ships an equivalent data product, map your consumers to it and retire your flow. Name the flows so that this later swap is a checklist, not an investigation.

Extension fields need their own step. If your Sales Cloud V2 carries custom fields, say machine type, project phase or AVC configuration data, plan how each one reaches the semantic layer and who owns it. On a clean tenant that is hours of modelling per field group, not weeks.

Pattern 2: pipeline-to-cash as the first model

Every client asks for it; few have it. Opportunities live in the CRM, orders and invoices in the ERP, and the join between them is a quarterly Excel exercise. With CRM and S/4HANA data in one BDC tenant, pipeline-to-cash becomes a modelling task instead of an integration project.

The join keys decide whether it works:

• Account to business partner. On the integrated stack, Sales Cloud V2 accounts replicate from or to S/4HANA business partners, so the key usually exists. Check duplicates and accounts created only in the CRM before modelling.
• Opportunity to sales order. The link exists only if the process creates it: a quote or order created from the opportunity carries the reference. Orders entered directly in the ERP need a mapping rule, or they stay outside the funnel.
• Product to material. Product master data should come from S/4HANA. Free-text products in opportunities cannot be joined later.

The model itself stays simple: won opportunities against order intake and billed revenue, by sales organisation, product group and period. The payoff is forecast accuracy measured against what was actually shipped, the number that turns CRM discipline from a management wish into a KPI. The integration architecture between Sales Cloud V2 and S/4HANA Public Cloud describes where these keys are created on the transactional side.

Pattern 3: keep real-time out of the analytics layer

The most common design mistake we run into is routing operational real-time needs through the analytics platform. A rep who needs live stock and pricing before a quote gets that from the application integration between Sales Cloud V2 and S/4HANA, not from BDC. Analytics tolerates refresh cycles; quoting does not.

Draw the line explicitly in the architecture document: transactions through application APIs, analysis through data products. Architectures that blur it inherit the weaknesses of both, slow quotes and fragile dashboards.

Pattern 4: one semantic model, many consumers

Once the foundation stands, resist per-team variants. The SAC story for management, the Databricks notebook of the analyst and a Joule agent answering “how is Q4 pipeline against last year?” should all read the same governed model. As soon as someone forks their own version of revenue, you are rebuilding the problem you paid to remove. Governance here is the product itself: one definition per measure, one owner per domain, change requests through that owner.

This is also where data quality starts to matter more than tooling. Duplicate accounts and orphaned opportunities flow straight into every consumer. We describe the fix sequence in why your CRM data is only as good as your data foundation.

Where this fits

We started this series with what BDC is and what happens to Datasphere. The patterns above are the practical middle. The strategic reason behind them is AI: agents are only as good as the model they read, and a governed pipeline-to-cash model is what a Joule agent needs to answer revenue questions with the same provenance as a report.

Running CRM and ERP analytics on one foundation is easiest when one team knows both sides of the seam. That is how we work, see why ERP and CRM from one partner matters. If you run Sales Cloud V2 and your analytics still lives in exports, our BDC practice starts with exactly this first model.

FAQ

Does Sales Cloud V2 have native data products in BDC?

Check the data-product catalogue for your release before you design anything. Where SAP ships a data product for the entities you need, consume it. Where it does not, bring Sales Cloud V2 data in once through its APIs or a replication flow into Datasphere, model it as your own governed data product, and replace it when SAP ships an equivalent.

Can I combine Sales Cloud V2 and S/4HANA data in one BDC model?

Yes, and that is the main reason to do this. Won opportunities from Sales Cloud V2 are joined with sales orders, billing documents and margins from S/4HANA in one semantic model, which gives you pipeline-to-cash reporting without custom middleware. The join keys (account to business partner, opportunity to sales order, product to material) need one alignment workshop; after that they hold.

What about real-time requirements?

Keep them out of the analytics layer. Pipeline and revenue analytics work on refresh cycles. A rep who needs live stock or pricing before a quote gets it from the application integration between Sales Cloud V2 and S/4HANA, not from BDC. Mixing the two requirements in one architecture is the most common design mistake we see.

How do custom extension fields in Sales Cloud V2 reach BDC?

Plan them explicitly. Extension fields such as machine type or project phase are not part of any standard model, so each one needs a mapping into your semantic layer with a named owner. On a clean tenant this is a modelling task of hours per field group, not a separate project.