Salesforce Data 360 vs. Microsoft Fabric: OneLake, the zero-copy bridge, and the job each one is actually for

We’ve had this meeting twice already — once about Snowflake, once about Databricks — and the Microsoft version has the same opening and a different second act. A company runs Microsoft Fabric: OneLake as the tenant-wide data lake, Power BI on top, the analytics estate consolidated onto one SaaS platform. Then the Salesforce account team pitches Data 360 — Data Cloud, renamed at Dreamforce 2025 and folded under the Agentforce 360 umbrella — as the data foundation for agents. Two platforms that both store data, both run SQL-shaped workloads, and both now put an agent in front of it. Finance asks which one the budget keeps.

It’s the wrong question, and the two vendors settled it in April 2024 when Salesforce launched the Zero Copy Partner Network with Microsoft as a named partner, committing to bidirectional zero-copy between Fabric and Data Cloud. So the honest post isn’t “which platform wins.” It’s how the bridge works, which direction is solid and which is still settling, and how to assign each platform the job it’s actually built for — because getting that boundary wrong is how you end up paying two vendors to do one job badly.

Two platforms, two centers of gravity

Strip the overlapping marketing away and the products are built for different problems.

Microsoft Fabric is a unified, general-purpose analytics platform, and OneLake is its heart — a single, tenant-wide data lake built on Azure Data Lake Storage, storing tables as Delta Parquet and interoperating with Apache Iceberg through metadata virtualization. Everything in Fabric — the Lakehouse, the Warehouse, Power BI’s Direct Lake mode, Data Factory pipelines, Real-Time Intelligence, notebooks — reads and writes that one lake. Its gravity is the Microsoft data estate: if your BI runs on Power BI and your cloud is Azure, Fabric is the consolidation play. Nothing in it assumes your data is about customers. Feed it general-ledger entries, telemetry, or clickstreams and it’s equally happy. It is a workbench for whatever analytical problem you have.

Data 360 assumes the opposite. Everything in it is organized around one entity — the customer — and one pipeline: ingest from CRM, commerce, and service; harmonize to the Customer 360 Data Model; run identity resolution to collapse duplicate records into unified profiles; compute segments and insights; and activate the result into journeys, ad platforms, Flows, record pages, and the retrieval indexes that ground Agentforce at runtime. It is not a workbench. It’s an assembly line for turning fragmented customer records into agent-ready context.

The distinction that decides most evaluations, and the one general-purpose lakehouses keep tripping on: identity resolution is not native to Fabric. OneLake stores whatever you model; it has no built-in notion that these three rows are the same person. Data 360 does that as configuration — match and reconciliation rules that link source records into unified profiles. If you want customer matching on the Microsoft side you don’t get it from Fabric; you get it from a separate product, Dynamics 365 Customer Insights, which is a different SKU with a different center of gravity. That gap is the single strongest reason Data 360 sits alongside Fabric rather than under it.

The bridge: what actually crosses it, and in which direction

Zero copy between the two runs both ways, but the two directions use different machinery and sit at different levels of maturity. Knowing which is which saves you a week of confusion and a bad architecture decision.

Data 360 shares out to OneLake. This is the more established direction. A Data 360 dataset is exposed to Fabric as a OneLake shortcut — a metadata pointer, “like a shortcut on your desktop,” that lets Fabric and Power BI query the data in place without moving or duplicating a row. The data stays governed by the Data 360 sharing model; Fabric reads it through the shortcut. For a team whose reporting lives in Power BI, this is the clean way to put unified customer profiles and segments in front of a Fabric analyst without building a pipeline or reconciling a second copy.

Data 360 federates in from OneLake. This is the newer direction, and it rides Data 360’s own zero-copy federation — which, importantly, comes in two flavors that behave very differently:

• Query federation issues a live SQL query to the external source’s query API over JDBC when Data 360 needs the data. Compute runs on both sides — Data 360 orchestrates, the remote engine executes — so you pay latency and compute in two places, but the data is always current.
• File federation skips the external compute entirely. Data 360 reads the underlying Apache Iceberg / Parquet files directly at the storage layer using its own Hyper engine. Salesforce has described scaling this path to over 120 trillion rows; it’s the better fit for large, high-volume datasets because there’s no remote warehouse spinning up and no second compute bill for the read. File federation is the direction Salesforce has been steering people toward, and it’s newer — treat its availability for any given source, OneLake included, as something to confirm against current release notes rather than assume.

So the mental model is: Fabric pulls Data 360’s resolved customer into the lake for analytics and Power BI; Data 360 pulls Fabric’s modeled analytical tables in to enrich profiles and ground agents. The zero-copy mechanics — and the cases where “zero copy” quietly materializes a cached copy — are the same ones we’ve mapped before; here the interchange formats are Delta and Iceberg, and OneLake’s metadata virtualization is what lets those two formats read each other without a conversion step.

The comparison that actually helps a buyer

Job by job, not feature by feature:

	Microsoft Fabric	Salesforce Data 360
Primary job	General-purpose analytics lakehouse in the Microsoft estate	Customer identity, activation, and agent grounding on the Salesforce platform
Data model	Whatever you design; medallion, domain-agnostic	Opinionated Customer 360 model (DLOs mapped to DMOs)
Storage	OneLake — Delta Parquet, Iceberg via virtualization	Managed store + zero-copy federation to external lakes
Identity resolution	Not native (separate product: D365 Customer Insights)	Native match/reconciliation into unified profiles
BI / reporting	Core strength: Power BI Direct Lake	Not its job — surfaces via CRMA / Tableau
Segmentation & activation	Assemble it	Native to journeys, ads, Flow, CRM surfaces
Agent grounding	Not its job	Retrievers and indexes that ground Agentforce
Compute billing	Fabric capacity units (F-SKUs)	Data 360 consumption credits
Wrong use	Being your CRM’s consent-aware activation layer	Being your enterprise analytics and BI lake

The pattern we recommend when a client owns both starts from one rule: every dataset has a single home, and the other platform gets a pointer.

Fabric is the analytical lake of record. All domains land in OneLake; pipelines, transforms, and Power BI modeling happen there. If a table needs heavy computation, cross-domain joins, years of retention, or a dashboard, it lives in Fabric. Adopting Data 360 shouldn’t demote OneLake an inch.

Data 360 owns only what activation and agents need — the harmonized customer model, identity-resolution output, consent, segments, insights, and the retrieval indexes that ground agents on a live record. Salesforce CRM data flows in through the native connector; Fabric tables federate in from OneLake; the resolved customer shares back out as a shortcut. Everything arrives by decision, not by default.

The anti-pattern is that design run backwards — bulk-copying OneLake into Data 360 “so it’s all in one place” (you’ve built a worse, pricier lakehouse), or rebuilding company-wide analytics on Data 360 queries, or standing up two customer models whose numbers never reconcile. Deciding which datasets sit on which side of the line is most of the work, and it’s exactly what a data and AI strategy engagement exists to settle before contracts are signed.

The gotchas that decide whether this works

Zero copy is not zero work, and it is emphatically not zero latency. Four things bite in production:

• Pushdown is close to all-or-nothing. A federated query is fast only when the whole query can be pushed to the remote engine. Mix a federated OneLake table with local Data 360 data in one operation and pushdown breaks, dragging rows across the wire. The subtle trap: a query touching the Individual object implicitly joins the local consent data, which can quietly force a large remote pull. Design queries to stay on one side.
• Federation is the wrong tool for conversational latency. If an agent needs a fact mid-conversation, a live federated query against OneLake makes the customer wait. The right move is to ingest or accelerate the hot path into Data 360 — materialize what an agent touches in real time and reserve federation for the reference data a segment reads occasionally.
• Governance is two planes. Fabric governs its side (OneLake security, Microsoft Purview); Data 360 governs its own (permissions, data spaces). Nothing unifies them across the bridge today. Plan for two policy planes and keep the mapping between them explicit.
• You bill on two meters. A live segment refresh against a federated OneLake table consumes Data 360 credits for the rows accessed and Fabric capacity units for any compute that runs on the Fabric side. Usually still cheaper than maintaining pipelines and duplicate storage — but an unfiltered scan of a large federated table will prove otherwise on two invoices in the same month.

The elephant: Microsoft sells the whole stack

Here’s what makes the Microsoft decision different from the Snowflake one and closer to the Databricks one. Microsoft doesn’t just sell a lakehouse — it sells Dynamics 365 Customer Insights (a CDP with AI identity stitching), Copilot everywhere, and Fabric’s own data agents. So the overlap with Data 360 isn’t hypothetical; a Microsoft-standardized enterprise can plausibly ask why it needs a Salesforce CDP at all when Customer Insights sits right there in the same tenant.

The honest answer is where the data lives and what the agents serve. Data 360’s advantage is its native wiring into the Salesforce estate — journeys, Service Cloud, record pages, and the Agentforce grounding that a lakehouse-native or Dynamics-native CDP has to integrate toward from outside. If your customer engagement runs on Salesforce clouds and your agents are Agentforce agents, the resolved profile wants to live next to them, and the bridge brings the analytical estate to it. If your customer engagement runs on Dynamics, the calculus genuinely flips — and no amount of zero-copy plumbing changes that.

Either way, the architectural discipline is the same: keep the boundary between the two platforms explicit and reversible. Own your identity-resolution rules, your segment definitions, and your activation logic as portable assets rather than deep, unspeakable configuration in one vendor’s console. Design so that if the strategic ground shifts, you can move a layer without re-resolving every customer from scratch. That’s good architecture regardless of the rivalry; the rivalry just makes it urgent.

Stop comparing platforms; assign jobs

A bidirectional, zero-copy bridge that each vendor promotes on its own blog tells you how they see the technical relationship, whatever their sales teams do at renewal. Fabric isn’t trying to be your CRM’s consent-aware activation layer. Data 360 isn’t trying to host your Power BI estate. They converge on features and diverge on jobs.

So reframe the evaluation the way we always do: which datasets need company-wide analytics, BI, and Azure-native engineering — that’s Fabric work. Which need identity resolution, activation, and agent grounding inside the Salesforce estate — that’s Data 360 work. What crosses the boundary, in which direction, and on whose meter? Answer it that way and the design for most Salesforce-plus-Fabric enterprises is boringly clear: keep Fabric as the analytical lake, scope Data 360 to identity and the agent surface, join them with OneLake shortcuts one way and federation the other, watch both meters — and keep the seam clean enough that you can renegotiate it when the platforms circle each other again.

Understanding the basics

Is Microsoft Fabric a replacement for Salesforce Data 360?

No. Fabric is a general-purpose analytics lakehouse for BI, engineering, and reporting across every business domain, centered on OneLake and Power BI. Data 360 is a customer-identity, activation, and agent-grounding layer attached to the Salesforce platform — and its defining capability, identity resolution, isn’t native to Fabric at all. Most enterprises that own both should connect them with zero-copy rather than choose: Fabric as the analytical lake, Data 360 as the activation and grounding layer.

How does zero-copy work between Data 360 and Microsoft Fabric?

It’s bidirectional and uses different machinery each way. Data 360 shares data out to Fabric as OneLake shortcuts — metadata pointers that let Power BI and Fabric query it in place. Data 360 reads Fabric data through its own zero-copy federation: query federation issues live SQL over JDBC (compute on both sides), while file federation reads the Iceberg/Parquet files directly at the storage layer with Data 360’s Hyper engine (no external compute). Neither direction persists a copy by default, though Data 360 acceleration can cache data locally to cut latency at the cost of some staleness and spend. Confirm the exact status of any given path against current release notes.

Does Microsoft Fabric do identity resolution?

Fabric itself does not — it’s an analytics lakehouse with no built-in customer-matching engine. Microsoft’s identity resolution lives in a separate product, Dynamics 365 Customer Insights, its dedicated CDP. That’s the honest nuance: “Microsoft has no identity resolution” is false, but “Fabric has no native identity resolution” is accurate, and it’s why Data 360 earns its place next to OneLake in a Salesforce-centric estate.

---

Trying to work out where your Fabric estate should end and Data 360 should begin — and how to keep the seam clean while Microsoft and Salesforce both sell you the whole stack? Talk to us. Drawing that boundary is exactly the work we do.