You're on SAP Business Data Cloud: Keep Every Model Built on SAP Data Products True to SAP's Meaning
Already on SAP Business Data Cloud? Bring SAP data product semantics into Data Workers as governed context, keep Databricks and Snowflake models aligned, and fix drift with approvals.
Your company runs on SAP, and SAP Business Data Cloud is where that data becomes usable outside the ERP. S/4HANA Cloud publishes SAP-managed data products "built on SAP's business process definitions". SAP Datasphere is the knowledge core where your team models, defines KPIs and builds custom data products, and the catalog runs access agreements. At SAP Sapphire in May 2026, SAP announced Joule Agents that create data products, generate planning models and answer questions "powered by governed data products in SAP Business Data Cloud and SAP Knowledge Graph". Through SAP BDC Connect, data products reach Databricks, Snowflake and Google BigQuery with zero copies (BigQuery generally available since August 4, 2026), and SAP has announced plans for Amazon Athena. SAP Business Data Cloud is where your ERP meaning lives. Data Context Wizard is where every agent reads it downstream, next to lineage, quality and usage, with a named owner on every fact.
That split matters once a data product leaves the formation. A journal entry data product lands in Databricks as a Delta Share, and an analytics engineer builds a dbt model on it with a company code mapping and a currency rule. SAP's meaning arrived intact; the model on top is your code, and it drifts when finance adds a company code. Data Workers is the agentic data platform that keeps that downstream layer aligned: it brings SAP's semantics in as context with provenance, catches the drift, and proposes the fix with an approval and a receipt.
Key takeaways
- •SAP Business Data Cloud keeps its job. Data Workers reads it and changes nothing inside SAP, by design.
- •Zero copy moves the data; your models still interpret it. The dbt models, notebooks and dashboards your team builds on shared data products are where meaning drifts.
- •SAP's definitions become governed context. Data Context Wizard records SAP KPIs and company code rules with their SAP source and a named owner, so every agent reads the same rule.
- •Fixes land downstream, with approvals. Data Workers proposes the dbt change with its blast radius, routes it to the owner in Spellbook, verifies against SAP totals and writes a receipt.
- •Start with a pilot. One domain, such as the finance close, read-only first, then one write class.
SAP Business Data Cloud holds the ERP meaning. Data Workers keeps it true downstream.
SAP's data products carry ERP meaning well: a journal entry arrives with its company code, ledger and currency types. When data products are shared to SAP Databricks, "you can now access semantic metadata directly in Unity Catalog" (generally available May 7, 2026). SAP BDC Connect for Snowflake shares data "while preserving full business semantics, lineage, and governance across both environments"; bidirectional sharing went GA on May 12, 2026, and SAP Snowflake was released as a BDC extension on May 27. Data Context Wizard holds the downstream graph: every table, model, metric and dashboard built on those data products, with lineage, owners, quality and freshness. SAP owns what the data means. Data Workers owns whether everything built on it still agrees.
Here is a month-end night with both in place. This is an illustration, not a customer case.
| Time | System | What happens |
|---|---|---|
| 18:00 | S/4HANA Cloud | Finance posts the first entries for company code 4100, a new Mexican subsidiary, in MXN |
| 22:30 | SAP Business Data Cloud | The journal entry data product carries the new company code and its currency, with SAP's semantics |
| 22:35 | Databricks | The data product, shared through BDC Connect as a Delta Share in Unity Catalog, shows the new rows with zero copies |
| 01:00 | dbt + Dagster | Dagster runs the dbt project; fct_gross_margin maps company codes to regions from a seed file and converts from a fixed currency column, so 4100 drops out |
| 01:20 | Data Workers | The check comparing fct_gross_margin to the data product's totals fails; Data Workers traces lineage to the share and the new company code and opens an incident |
| 01:25 | Data Workers | It reads SAP's definitions for company code and currency type, recorded earlier as authoritative with their SAP source |
| 07:40 | Data Workers | It proposes a dbt diff adding 4100 to the mapping and reading the currency from the data product's own field, with the blast radius: three models and two Power BI reports |
| 08:05 | Spellbook | The analytics engineer who owns the finance models reviews the diff and approves; dbt CI passes |
| 08:10 | Dagster | Data Workers reruns the affected partitions |
| 08:30 | Databricks | Gross margin by company code is back on its monitor_metrics baseline, and the controller confirms it against the data product's totals |
| 08:35 | Power BI | The margin report is right before the 9:00 close call, and it matches SAP Analytics Cloud |
SAP Business Data Cloud did its job: the new company code reached Databricks with its meaning attached and nothing copied. The break was in code SAP doesn't run. Data Workers found it at 01:20, used SAP's definition as the reference, and fixed the model with one approval and one receipt.
| Job | What SAP Business Data Cloud does | What Data Workers does |
|---|---|---|
| The meaning | Defines data products on SAP's business process definitions; holds KPIs, glossary terms and SAP Knowledge Graph | Records SAP's definitions as governed context with their source, and serves them to every agent and every downstream model |
| The sharing | Shares data products to Databricks, Snowflake and BigQuery with zero copies through BDC Connect | Follows lineage across the share into every model, notebook and report built on it |
| The question | Joule Agents answer from governed data products in SAP's own apps | Answers from the downstream models too, with the definition, owner and freshness behind each number |
| The drift | Keeps the data product consistent with its source system | Catches downstream models that disagree with SAP's totals or definitions |
| The fix | Changes inside SAP run through SAP's own modeling and governance | Proposes the downstream change with its blast radius, routes it to the owner, applies it reversibly |
| The proof | Shows each data product's lifecycle, release and functional status | Re-checks the models against their baselines, with the owner's sign-off against SAP totals, and writes a receipt for the change |
Why doesn't SAP Business Data Cloud just do this itself?
Because SAP built the right product for its job: define SAP semantics once, govern data products inside the formation, and share them outward with their meaning intact. Master Data Governance keeps master data clean and Joule works inside SAP's own tools. That focus is why data products arrive downstream in such good shape.
What happens after the share is a different product. Your Databricks or Snowflake account holds dbt models, notebooks, semantic layers and BI reports that your team writes and SAP doesn't run. Keeping them aligned means lineage across SAP, the lakehouse, the orchestrator and BI; reconciling SAP's KPIs against the metrics in dbt and Power BI; blast-radius scoping, approvals by model owner, rollback; and accountability for changes in systems outside SAP's formation. That is the product Data Workers is.
Every tool owns a slice. Data Workers covers the whole lifecycle
SAP Business Data Cloud owns one slice of the lifecycle, and owns it well: ERP data products and the meaning behind them, plus analytics and planning. Each point tool adds another console, contract and handoff. Data Workers covers the whole lifecycle with one context, one approval flow and one audit trail, and builds on SAP where your ERP meaning lives.
| Stage | Data Workers | SAP Business Data Cloud | Why we scored it this way |
|---|---|---|---|
| Catalog & Context | 9 | 9.5 | SAP's home stage: curated data products built on SAP's business process definitions, a catalog with glossary terms, KPIs and domains, and SAP Knowledge Graph. Data Workers carries that meaning to every downstream model, joined to lineage, quality and usage. |
| Analytics & Insights | 8 | 9 | SAP's second home stage: SAP Analytics Cloud for analytics and planning, and Joule Agents that answer from governed data products. Data Workers answers metric questions through governed definitions across every platform. |
| Data Quality | 8 | 5 | SAP Master Data Governance and Reltio keep master data clean, and data products carry a functional status. Data Workers writes, runs and repairs the checks on the models built from those data products. |
| Observability & Incidents | 8.5 | 3 | Task chains report their own runs and failures inside BDC. Data Workers detects a break in the downstream lakehouse, traces it to the source change, fixes it and verifies the result. |
| Pipelines & Ingestion | 8.5 | 7 | Datasphere replication flows, task chains and zero-copy sharing through BDC Connect move SAP data well. Data Workers builds, reruns and backfills the downstream pipelines behind approvals. |
| Schema & Migration | 8 | 6 | BW modernization paths and data product versions are SAP's to manage. Data Workers catches upstream schema changes in the dbt manifest and in review, assesses impact downstream and drafts each migration with rollback SQL for the owner to apply. |
| Governance & Access | 8.5 | 7 | Strong over its own surface: access requests and agreements, domains and data access controls in the formation. Data Workers proposes and applies grants on the platforms the data products are shared to. |
| Security & Privacy | 8 | 6.5 | Data products are tagged for personal and sensitive personal data, and spaces isolate access. Data Workers flags sensitive column names in pull request review and proposes masking for the owner. |
| Cost / FinOps | 8 | 4 | BDC meters usage in capacity units. Data Workers traces Snowflake credits to the dbt model behind them and drafts the fix for its owner. |
| MLOps & Models | 7.5 | 6 | SAP Databricks and SAP AI Core train and serve models on SAP data. Data Workers keeps the data under those models healthy and connects to MLflow and W&B. |
How SAP Business Data Cloud and Data Workers work together
People keep working in Joule and in their assistant or coding agent. Spellbook Data Catalog (in preview) is where the data team reviews each change, its approver and its rollback. Underneath, Context Wizard keeps one governed context graph, the Data-Agents Swarm does the work with 20+ specialist agents, the Autonomous Data-Conductor runs each fix end to end (detect, diagnose, fix, review, verify, remember), and per-domain guardrails hold approvals, receipts and rollback.
How Data Workers connects today. Data Workers connects to SAP Business Data Cloud over SAP's APIs today. The SAP Datasphere consumption OData API lists exposed spaces and assets and returns their data and metadata, read-only by SAP's design, with an OAuth client-credentials technical user as the identity. Downstream, Data Workers' Databricks and Snowflake connectors read the shared tables, columns and column comments, so lineage runs from the data product into every model built on it.
Example: reading exposed assets from SAP Datasphere (technical user, read scope)
POST <token URL of your Datasphere OAuth client>
grant_type=client_credentials (client ID and secret from that OAuth client)
GET https://<tenant_url>/api/v1/datasphere/consumption/catalog/spaces
GET https://<tenant_url>/api/v1/datasphere/consumption/catalog/spaces('<space_id>')/assets
GET https://<tenant_url>/api/v1/datasphere/consumption/relational/<space_id>/<asset_id>/$metadataBring your own context, with SAP as the authority. The data team records SAP's KPIs, terms and company code rules in Context Wizard with define_business_rule, citing the SAP data product or KPI as the source, or imports a batch with import_tribal_knowledge, which keeps the author on each entry. An owner marks the SAP data product as the canonical source for a metric with mark_authoritative, and any agent can ask get_authoritative_source before it answers. Agents can propose context; only a named human makes a fact authoritative. When a dbt metric disagrees with the SAP KPI it implements, the conflict goes to the owner, never to an automatic overwrite. For the pattern across ontologies and semantic layers, see the hub, bring your own context.
Setup for the data team. Every Data Workers agent is an MCP server, listed in your client's MCP config with the open-source repo's start-agent.sh:
Example: .cursor/mcp.json with Data Workers agents for the SAP domain
{
"mcpServers": {
"dw-context-catalog": {
"command": "/path/to/dataworkers-claw-community/start-agent.sh",
"args": ["dw-context-catalog"]
},
"dw-incidents": {
"command": "/path/to/dataworkers-claw-community/start-agent.sh",
"args": ["dw-incidents"]
}
}
}List the tools with the client's own command (for example /mcp). This guide uses resolve_metric, trace_cross_platform_lineage and blast_radius_analysis on dw-context-catalog, and diagnose_incident and remediate on dw-incidents.
One request end to end, L0 to L4. The autonomy ladder is set per domain.
- •L0 manual. Your team finds the missing company code at the close call and fixes the seed by hand.
- •L1 observe. Data Workers resolves "gross margin" to the SAP KPI and the dbt metric, walks lineage to Power BI and flags the disagreement for 4100.
- •L2 propose. It drafts the dbt diff with its blast radius; nothing ships until the owner approves and CI passes.
- •L3 act reversibly. For proven change classes, such as reruns and backfills, it starts the change through the orchestrator with the undo recorded first and re-checks the quality assertions; a failed check goes to a named person, who runs the undo if it is needed.
- •L4 autonomous. For a scoped domain like finance mart reconciliation, it fixes overnight and leaves the receipt.
A change inside SAP itself always goes to its SAP owner as a proposal, by design. Each step up is a per-domain decision, and you can step back down any time. Read is it safe to let AI agents change production data for the safety model and where does our data go for data and credentials.
For both sides of the share, read Data Workers on Databricks and Data Workers on Snowflake; for CRM data, you're on Salesforce Data Cloud; for the platforms' own context layers, you're on Databricks Genie Ontology and you're on Snowflake Horizon Context.
What changes for your team
SAP Business Data Cloud gave the business one governed version of its ERP data. Data Workers gives the data team a crew, so the models built on it agree with SAP every morning.
- •Incidents. A new company code, plant or ledger that a mapping misses is traced, fixed and verified before the close call.
- •Data quality. Every model built on a data product gets checks that reconcile it to SAP totals.
- •Cloud spend. Cleanups of copies of SAP tables made before zero-copy sharing are proposed to the owner after a dependency check.
- •Access. A request for a shared data product on the Databricks or Snowflake side arrives as a time-boxed grant proposal for its owner.
- •Audits. SAP keeps each data product's history. Data Workers records who changed which downstream model, why, and how to undo it.
- •Migrations. BW logic moves to models on data products in approved, parity-checked waves; see you're on SAP BW and Datasphere.
Finance stops reconciling the lakehouse against SAP Analytics Cloud at every close.
Keep SAP Business Data Cloud, or consolidate?
Keep SAP Business Data Cloud if you love it; Data Workers works with it from day one. Many teams consolidate once Data Workers runs that slice too.
For SAP-run companies the answer is to keep it: it is the authority on what your ERP data means. Data Workers adds the slice after the share. Where teams consolidate, it is usually a separate lakehouse catalog, a duplicate metric glossary, or extraction jobs zero-copy sharing replaced. Weighing a build? Read build it ourselves with Claude Code and MCP servers: reading an API is the easy part; the context graph, approvals and rollback are the work.
The case for your CFO
The outcome: SAP Business Data Cloud gets SAP data to analytics and AI with its meaning intact. Data Workers makes sure the numbers built on it, in Databricks, Snowflake and every dashboard, still match SAP at close, and repairs them when they don't. Margin, revenue and working capital reports stop disagreeing with the ERP.
The risk story: Data Workers reads SAP with a read-only technical user and changes nothing inside SAP. Downstream, autonomy is set per domain from L0 manual to L4 autonomous; each change has a blast radius, a named approver, a rollback path and a receipt. There is zero migration.
Why now: in 2026 zero-copy sharing put SAP data products into Databricks, Snowflake and BigQuery, and agents answer from all of them. A drifted model now misleads every agent and report that reads it.
The first win is the finance close: read-only first, SAP's KPIs recorded as authoritative, models checked against their baselines overnight, then one write class behind approvals. What stays the same: SAP licenses, data products, Datasphere models, warehouse grants and your dbt review process. For the numbers, see the ROI of agentic data operations.
The sentence to repeat upstairs: "SAP defines what our numbers mean; Data Workers makes sure every model built on SAP data still agrees, and fixes it with an approval and a receipt when it doesn't."
Getting started
Start with a pilot. Pick a domain where SAP data products feed Databricks or Snowflake models, such as the finance close, connect Data Workers read-only, record your SAP KPIs as authoritative, and reconcile for a few closes before the first write class. The pilot path and plans are on the pricing page, and the pilot is credited in full against the first year.
FAQ
Doesn't SAP Business Data Cloud already keep business semantics intact? Yes, for the data products: they carry SAP's semantics into Databricks, Snowflake and BigQuery. The dbt models, notebooks and reports your team builds on them are your code, and Data Workers keeps that layer aligned with SAP's definitions.
Does Data Workers write into SAP? No, by design. It reads SAP with a read-scoped technical user. Fixes land downstream in dbt, the orchestrator or the warehouse; anything that belongs in SAP goes to its owner as a proposal.
How does Data Workers connect to SAP Business Data Cloud? Over SAP's APIs today: the SAP Datasphere consumption OData API for exposed assets and their metadata, plus the shared data products where they land in Unity Catalog or Snowflake, through Data Workers' Databricks and Snowflake connectors. SAP doesn't document an MCP server for Business Data Cloud, so the API is the path.
We use Joule Agents. Do we need both? They do different jobs. Joule Agents create data products, generate planning models and answer questions inside SAP's applications. Data Workers works where your data team builds on SAP data and keeps those models aligned.
What happens when a dbt metric disagrees with an SAP KPI? Data Workers flags the conflict with both definitions, the lineage and the affected reports, and routes it to the named owner, who decides. The decision is recorded with its source.
Does zero-copy sharing mean there are no pipelines left to watch? The extraction jobs go away. The transformations and reports built on the shared data still run nightly, and that is where a new company code shows up first.
Sources
- •SAP, SAP Business Data Cloud product page, https://www.sap.com/products/data-cloud.html (checked Oct 2, 2026)
- •SAP, Open data ecosystem (SAP Business Data Cloud Connect for Databricks, Snowflake, Google BigQuery, Microsoft Fabric, Amazon Athena), https://www.sap.com/products/data-cloud/open-data-ecosystem.html (checked Oct 2, 2026)
- •SAP, SAP Datasphere in Business Data Cloud, https://www.sap.com/products/data-cloud/datasphere.html (checked Oct 2, 2026)
- •SAP, Business data fabric in Business Data Cloud, https://www.sap.com/products/data-cloud/business-data-fabric.html (checked Oct 2, 2026)
- •SAP, SAP Databricks in Business Data Cloud, https://www.sap.com/products/data-cloud/databricks.html (checked Oct 2, 2026)
- •SAP, SAP Snowflake, https://www.sap.com/products/data-cloud/snowflake.html (checked Oct 2, 2026)
- •SAP News, Accelerate the Autonomous Enterprise with SAP Business Data Cloud (May 13, 2026), https://news.sap.com/2026/05/sap-bdc-accelerate-autonomous-enterprise/ (checked Oct 2, 2026)
- •SAP News, SAP and AWS bi-directional zero-copy data sharing, plans for SAP BDC Connect for Amazon Athena (May 12, 2026), https://news.sap.com/2026/05/sap-aws-next-generation-ai-bi-directional-zero-copy-data-sharing-sap-bdc/ (checked Oct 2, 2026)
- •SAP News, SAP AI-native North Star architecture (SAP Knowledge Graph) (June 8, 2026), https://news.sap.com/2026/06/sap-ai-native-north-star-architecture-technical-backbone-autonomous-enterprise/ (checked Oct 2, 2026)
- •SAP Help Portal, What's New in SAP Business Data Cloud (GA entries May 7, May 12, May 27 and Aug 4, 2026), https://help.sap.com/docs/SAP_BUSINESS_DATA_CLOUD/cbce6bb04a6e4546aa4a44e1daa55599/ab4b1ecedd244f068756dff01b7104d6.html (checked Oct 2, 2026)
- •SAP Help Portal, Provisioning SAP Business Data Cloud Connect, https://help.sap.com/docs/SAP_BUSINESS_DATA_CLOUD/f7acf8c9dad54e99b5ce5ebc633ed8e1/ccbd8fe7c2394009b546b73b1dd6c164.html (checked Oct 2, 2026)
- •SAP Help Portal, Sharing SAP Business Data Cloud Data Products to SAP Databricks, https://help.sap.com/docs/SAP_BUSINESS_DATA_CLOUD/3708ee482fc441ef8bb91711b1629109/775c3c175b364d489a23df8caf741127.html (checked Oct 2, 2026)
- •SAP Help Portal, Catalog Concepts, https://help.sap.com/docs/SAP_BUSINESS_DATA_CLOUD/08752d72ed8d4f3683b110d3e76689c3/5772386034824e2ba7146fe7b3109d21.html (checked Oct 2, 2026)
- •SAP Help Portal, Data Product Details, https://help.sap.com/docs/SAP_BUSINESS_DATA_CLOUD/08752d72ed8d4f3683b110d3e76689c3/71f4d1599dba4aa59e6682a314650cf7.html (checked Oct 2, 2026)
- •SAP Help Portal, Import Key Performance Indicators, https://help.sap.com/docs/SAP_BUSINESS_DATA_CLOUD/08752d72ed8d4f3683b110d3e76689c3/adc41e274a344172a7ebecf8350e6d3a.html (checked Oct 2, 2026)
- •SAP Help Portal, SAP Datasphere: Consuming Data via the OData API, https://help.sap.com/docs/SAP_DATASPHERE/43509d67b8b84e66a30851e832f66911/7a453609c8694b029493e7d87e0de60a.html (checked Oct 2, 2026)
- •Data Workers, client setup, https://dataworkers.io/opensource-docs/client-setup/ (checked Oct 2, 2026)
- •Data Workers open-source repository, tool registrations, https://github.com/DataWorkersProject/dataworkers-claw-community (checked Oct 2, 2026)