Connecting Data 360 to Microsoft Fabric: the OneLake bridge, and the beta caveat

If your organization runs on Microsoft, the zero-copy story used to have a hole in it. Salesforce shipped a clean connector for Snowflake, Databricks, BigQuery and Redshift, and every one of those write-ups assumed your lakehouse was one of the four. Fabric shops read them and asked the obvious question: where is OneLake.

As of the Summer ‘26 release, it is here, and the important detail is that the two halves of the bridge are at different stages of maturity. Sharing Data 360 data out to OneLake is the established zero-copy path, and it is the one most Microsoft shops actually want. Federating OneLake tables back into Data 360 is newer, and it landed in beta.

So the rule for planning a Fabric integration right now is short. Build the share-out into production if that is your direction, and treat the federation-in path as a pilot you validate, not a dependency you ship on. Below is each direction, the Entra ID setup that catches Salesforce teams, and where the whole thing earns its keep.

Two directions, and people conflate them constantly

Every zero-copy conversation goes sideways for the same reason: “connect Data 360 to Fabric” describes two different features that point opposite ways, and the requirements diverge the moment you pick one.

Federation in means Data 360 reads tables that live in OneLake, without ingesting them. The data stays in Fabric, and Data 360 queries it in place as if it were local. You reach for this when the system of record for something, a product catalog, a finance table, a warehouse-computed metric, lives in Fabric and you want an agent or a segment to use it.

Sharing out means Data 360 exposes its own objects to Fabric, again without copying. Your unified profiles, calculated insights, and Data Lake Objects become readable from OneLake, so a Fabric analyst or a Power BI report can query Salesforce-governed data without an ETL job moving it first.

Same partnership, same zero-copy principle, two different setups. Decide which one you are building before you open a single screen, because the auth, the object mapping, and the maturity are not the same on the two sides. If the zero-copy concept itself is fuzzy, that piece is worth reading first.

The beta caveat that changes your rollout plan

Federation from Microsoft Fabric OneLake was beta as of Summer ‘26. The beta status is a planning fact, not a footnote.

A beta connector is fine for a proof of concept and wrong for a production dependency. If a live segment, a customer-facing agent, or a nightly activation depends on a beta federation connection, you have coupled a shipping business process to a feature whose behavior and limits can still move between releases. When it hiccups, the blast radius is your production audience.

The same release tells you what mature looks like by comparison. In Summer ‘26, federation from the AWS Glue Data Catalog reached general availability, and the Databricks file-federation connector gained identity-provider auth. Those are production-grade. Fabric federation is on the same road and not yet at the same milestone.

Before you design anything on the federation-in path, open Data 360 setup and confirm the connector’s current status for your org, because it may have advanced past beta since Summer ‘26 and it may not have. Do not take a blog post’s word, this one included, for a release state you can read directly in your own org.

Here is the part that gets lost in the beta noise: the direction most Microsoft-standardized organizations need is the mature one.

Most teams do not want to pull Fabric data into Salesforce. They want the reverse. They have spent a year building the unified customer profile, the identity resolution, the calculated insights, and now the data team wants that in Fabric and Power BI without rebuilding it or syncing it on a schedule. Sharing Data 360 out to OneLake gives them exactly that, with no copy and no pipeline to maintain.

The mechanism is the open-table format doing its job. Data 360 exposes its shared objects as Apache Iceberg tables, and Fabric reads them through a OneLake shortcut that points at that table. Nothing is duplicated.

A query in Power BI or a Fabric notebook resolves against the live Salesforce-managed data, and the Data 360 sharing model still enforces who is allowed to see what. If the Iceberg layer under all of this is unfamiliar, the file-federation walkthrough covers the format and why it is the substrate, not a separate feature.

The practical win is governance. When the profile is shared rather than copied, there is one definition of a customer, and Fabric reads it instead of forking it. The alternative, a nightly export into OneLake, gives you a second copy that drifts from the first and a lineage question nobody can answer six months later.

The auth is Entra ID, and that is the setup Salesforce admins miss

Connecting these two platforms means authenticating across two identity systems, and the Fabric side runs on Microsoft Entra ID. Entra ID is the piece a Salesforce-native team is least ready for.

OneLake shortcuts and connections authenticate with either an organizational account or a service principal. For anything automated, you want the service principal: an Entra ID app registration with a tenant ID, an application ID, and a client secret, granted access to the specific OneLake workspace and item.

A person’s organizational account works for a quick test and is the wrong choice for a standing connection, because it breaks the day that person changes roles or leaves.

Two failure modes show up early. The first is scope: the service principal has to be granted access to the exact workspace and path, and a principal that authenticates fine but sees nothing is almost always a missing grant on the Fabric side, not a Salesforce problem.

The second is secret rotation. A client secret expires, and when it does the connection stops, so whoever owns the Salesforce side needs to know the Entra secret lifecycle or the integration dies on a date nobody wrote down.

Sort out who owns the Entra ID app registration before you start. On most joint projects the Salesforce team does not have rights to create it, and the Microsoft team does not know why Data 360 needs it. That handoff, not the connector UI, is where these projects stall.

The mapping step still decides everything downstream

Once a federation connection is live, its tables land in Data 360 as external Data Lake Objects, and a DLO is not yet something an agent or a segment can use. You still have to map it up into the data model, and that mapping is where the value is made or lost.

That mapping governs every source in Data 360, and skipping past it is the most common way a connection that “works” produces nothing useful. A federated OneLake table becomes a DLO; that DLO has to be mapped to a Data Model Object and, if it describes people, tied into identity resolution before a unified profile can read it.

The DLO-versus-DMO distinction is the one to be solid on, because it decides what everything downstream can and cannot see.

Once mapped, you query it like any other Data 360 object. A federated product table from Fabric reads through the standard SQL surface:

SELECT
    p.ssot__Id__c        AS product_id,
    p.ProductName__c     AS product_name,
    p.ListPrice__c       AS list_price
FROM Fabric_Product_Catalog__dll AS p
WHERE p.IsActive__c = true
LIMIT 200;

The query runs against the live OneLake table. There is no copy in Salesforce to go stale, which is the entire point, and also the thing that shapes how you should design around it.

What query in place changes about your design

A federated table is not a local table wearing a different name, and treating it like one is how the latency surprises land. The read crosses the network to Fabric every time, so the round trip depends on OneLake’s performance, the size of what you are scanning, and how much the query can push down to the source.

That reality sets a few rules. Do not put a federated OneLake read on a synchronous, user-facing path that has to return in milliseconds; a rep waiting on a page load will feel a cross-cloud scan. Do use it for segmentation, batch enrichment, and grounding where near-real-time is fine and freshness beats speed. And design the query to filter early, so you scan what you need and not the whole table across the wire.

Cost lives on both platforms and it is easy to miss one side. Data 360 meters the queries that federation and sharing drive, and the credit-optimization playbook is the reference for keeping that in check. Fabric meters its own compute and storage when it serves those reads. A federated query that scans a billion rows is not free just because nothing was copied, and the invoice arrives from two vendors, not one.

When to reach for Fabric federation over a copy

Federation is the right tool when the data genuinely belongs in Fabric, changes often enough that a copy would be stale, and is read in a batch or grounding context rather than a hot synchronous one. A warehouse-computed propensity score that Fabric recomputes nightly and an agent needs for grounding is a clean fit.

Reach for ingestion instead when you need the data resident for very high-frequency access, when you have to join it heavily against Salesforce data in ways federation makes slow, or when the source cannot tolerate the query load your use imposes. And reach for sharing out, not federation at all, when the actual need is Fabric reading Salesforce data, which, again, is what most Microsoft shops are really asking for once you get past the phrasing.

The Data 360 versus Fabric comparison sits underneath this decision, because the reason a customer runs both platforms shapes which direction of the bridge they need. The connector does not settle the architecture question; it just removes the copy.

What I would do

If you are a Microsoft shop bringing Data 360 online, build the share-out first. It is the mature path, it is governance-clean, and it is almost certainly the direction your data team wanted before anyone said the word federation. Get the Entra ID app registration sorted early, because that handoff is the real critical path, and let Fabric read the unified profile through a shortcut instead of copying it.

Treat federation-in as a pilot until you have confirmed its status in your own org and watched it hold under real query patterns. A beta connector earns production trust the same way anything else does, by being boring for long enough. Until then, keep your shipping processes off it, and keep the copy you were about to avoid as the fallback you do not delete yet.

Understanding the basics

Can Data 360 connect to Microsoft Fabric with zero copy?

Yes, in both directions, though at different maturity levels as of the Summer ‘26 release. Data 360 can share its objects out to Microsoft Fabric OneLake as Apache Iceberg tables that Fabric reads through a shortcut, which is the established zero-copy path. It can also federate OneLake tables back into Data 360 and query them in place, and that federation-in connector was in beta as of Summer ‘26, so confirm its current status in your own org before building on it.

Federation means Data 360 reads external data where it lives, so a table in OneLake stays in Fabric and Data 360 queries it in place. Sharing means Data 360 exposes its own data to an external platform, so Fabric can read a Salesforce-governed profile without a copy. They point in opposite directions, and a Fabric integration usually needs one specific side, most often sharing out, so decide which before you configure anything.

What authentication does the Data 360 Fabric connector use?

The Fabric and OneLake side authenticates with Microsoft Entra ID, using either an organizational account or a service principal. For any standing, automated connection you want a service principal, which is an Entra ID app registration with a tenant ID, application ID, and client secret, scoped to the specific OneLake workspace and item. Plan for who owns that app registration and for client-secret rotation, since an expired secret silently stops the connection.

Is federating Microsoft Fabric into Data 360 production-ready?

As of Summer ‘26 the OneLake federation-in connector was beta, so it was suited to proofs of concept rather than production dependencies. By contrast, AWS Glue Data Catalog federation reached general availability and Databricks file federation gained identity-provider auth in the same release. Check the connector’s current status in Data 360 setup for your edition, because release states change between versions and the setup screen is the authoritative source.

A cross-cloud data bridge is easy to stand up and easy to design wrong, and the beta line is one of several places a Fabric integration goes sideways. Talk to us if you want the direction and the identity setup designed once and correctly, or see how our Data Cloud and integration practice makes unified data usable across the platforms you already run.