SAP Business Data Cloud Data Products Explained

Since SAP announced Business Data Cloud (BDC) in February 2025, the question we hear most is not about Databricks. It is simpler: “What exactly is a data product, and does it replace what we built?” That is the right question. Data products are the building block everything else in BDC stands on.

For what SAP announced when, see our SAP Business Data Cloud timeline 2025 to 2026. This post goes one level deeper.

TL;DR: A data product is a curated, SAP-managed data set with its business meaning attached, shared without copying. SAP’s first data products covered S/4HANA finance, spend and supply chain, SAP Ariba and SAP SuccessFactors. Intelligent applications are built on top of them. Where no CX data product exists for your release, Sales Cloud V2 and Service Cloud V2 customers bridge through Datasphere. Start with one data product and one question.

The problem with the old way

Classic SAP analytics follows a familiar pattern. You pick extractors or CDS views, replicate tables into BW or Datasphere, and rebuild the business logic on the other side. What is “net revenue”? Which document types count? Which status means “delivered”?

That logic already exists in the source application. You rebuild it anyway, and then you maintain it through every release. Most of the cost of an analytics project sits there, not in the dashboards.

What a data product is

In BDC, a data product is SAP taking over that rebuilding for its own applications. Four properties matter:

• Curated. It is not a raw table dump. It is a business-level data set, such as journal entries or purchase orders, shaped for analysis.
• SAP-managed. SAP builds it, delivers it and keeps it current when the source application changes. Your team does not maintain the pipeline.
• Semantically rich. The data comes with metadata: field meanings, relationships, units, currencies. Datasphere and SAP Analytics Cloud can use that without you redefining it.
• Shared, not copied. Data products sit in the BDC object store and are shared through Delta Sharing. Consumers read them without creating another copy in another system.

You activate a data product in BDC and it becomes available to Datasphere for modelling, to SAP Analytics Cloud for reporting and to SAP Databricks for data science.

Which data products SAP shipped first

SAP’s first catalogue concentrates on the areas with the most standardised processes:

Source	Domains
SAP S/4HANA	Finance, spend, supply chain
SAP Ariba	Spend and procurement
SAP SuccessFactors	Learning and talent

That is a sensible first wave: finance and procurement data look similar across companies, so a managed model fits many customers. It also means large areas are still open. Check the catalogue for your release before you plan around a specific data product. Coverage grows in waves: in May 2025 SAP promised hundreds of new data products across the Business Suite.

How intelligent applications sit on top

Intelligent applications are the next layer. SAP called them insight apps at launch and renamed them at Sapphire 2025. They are prebuilt analytics and planning content; in October 2025 SAP listed Finance, People and Cloud ERP Intelligence as generally available.

The stack looks like this:

1. Data products deliver the curated data.
2. Semantic models in Datasphere combine and describe it.
3. SAP Analytics Cloud content presents it as dashboards and planning.

An intelligent application packages all three. That only works because the data product underneath is standardised. Without it, every application would need a custom data layer first.

How this differs from extractors and replication

	Classic extractors / replication	Data products
Who models the business logic	Your team or your partner	SAP
Maintenance on release changes	Yours	SAP’s
Data movement	Copies into BW or Datasphere	Shared via Delta Sharing
Custom fields and objects	Yes, if you build it	Only what SAP includes
Non-SAP and uncovered SAP data	Yes	No, integrate separately

The trade-off is clear. You give up control over the model and gain freedom from maintaining it. For standard finance and procurement data, that is a good trade for most mid-market companies. For heavily customised processes, you will still model parts yourself.

Why CX data is the gap

SAP’s first data products are ERP, procurement and HR. Revenue Intelligence, the application SAP positions for sales and service data, was in restricted preview in SAP’s last public status we can cite, and SAP has not published which Sales Cloud V2 or Service Cloud V2 objects it reads. For companies that run SAP CX, that leaves the most interesting join open: pipeline, quotes and service cases next to orders, invoices and margins.

The gap is real, but it is bridgeable with tools you already have:

• Replication into Datasphere. Pull accounts, opportunities, quotes and cases from Sales Cloud V2 and Service Cloud V2 into Datasphere and model them next to the S/4HANA data products.
• Event-driven integration. Push changes through SAP Integration Suite into Datasphere when near-real-time matters.
• Shared keys. Make sure account, product and employee keys match between CRM and ERP. If they do not, no model will reconcile the numbers.

We connect Sales Cloud V2, Service Cloud V2 and S/4HANA Public Cloud data and work with Datasphere, so we see this join every day. The hard part is rarely the technology. It is agreeing which system owns which field.

What this means for you

For Swiss mid-market companies on S/4HANA Public Cloud or SAP CX:

1. Map your current extractors. List which ones cover standard finance, spend or supply chain content. Those are candidates to replace with data products.
2. Keep custom logic where it is. Custom fields and processes will not be in SAP’s data products. Do not plan as if they will.
3. Plan the CX bridge now. If pipeline-to-cash is your question, the CRM side needs your own integration into Datasphere. That work does not depend on SAP’s roadmap.
4. Fix master data first. A data product with clean structure on top of duplicate accounts still gives wrong answers.
5. Size the cost before committing. SAP prices BDC on Capacity Units; its pricing page describes the model. Size it for your first use case, not for the whole platform.

First steps

Pick one question that management already asks, ideally one that needs ERP data a data product covers. Activate that one data product, model it in Datasphere and show the result to the person who owns the number. Add CRM data in the second step.

If you want help choosing that first data product, or planning the CX bridge into Datasphere, see our Business Data Cloud page and get in touch. A short call is enough to sort out where to start.

FAQ

What is a data product in SAP Business Data Cloud?

A curated data set from an SAP application, delivered with its business meaning and kept current by SAP. It is stored in the BDC object store and shared without copying to Datasphere, SAP Analytics Cloud or SAP Databricks.

Which data products are available?

SAP’s first data products cover finance, spend and supply chain from S/4HANA and SAP Ariba, plus learning and talent data from SAP SuccessFactors. Check the catalogue for your release before you plan, because coverage grows in waves.

Do data products replace my extractors?

For the standard content SAP covers, that is the intent. For custom fields, custom objects and applications without data products, you still integrate yourself, typically through Datasphere.

How do I get SAP Sales Cloud V2 data into BDC?

Check the data-product catalogue for your release first. Where no Sales Cloud V2 data product exists, you replicate the data into Datasphere, or push changes event-driven through SAP Integration Suite, and model it next to the S/4HANA data products.