Microsoft Fabric for Dynamics 365 and CRM: The Data Platform Beneath Your Analytics

Microsoft Fabric for Dynamics 365 and CRM: the data platform beneath your analytics

When leadership looks at a Power BI dashboard, they see the top of a stack. The numbers are only the top layer. Underneath sits the question that decides whether the analysis can be trusted: where does the data come from, and how did it get there?

For organisations on Dynamics 365, the answer has historically been a mix of exports, Synapse Link, data warehouses and integrations someone built a few years ago. Microsoft Fabric is Microsoft's attempt to consolidate this into one layer, with OneLake as the shared data lake beneath the whole Power Platform stack.

This article explains what Fabric actually is, how Dynamics 365 data connects to it without ETL, what it costs, and (most importantly) when it pays off and when it does not.

What is Microsoft Fabric, and how does it relate to Dynamics 365?

Microsoft Fabric is a unified analytics platform that ties together data engineering, data warehousing, real-time analytics, data science and Power BI in a single service. At its core sits OneLake: one logical data lake for the whole organisation, where all data is stored in the open Delta-Parquet format rather than in separate silos.

The point is not to replace Dynamics 365 or Dataverse. Dynamics remains the system where data originates. Fabric is the layer where data from many sources is gathered, refined and made ready for analysis and AI. Power BI is still the window most people look through, but in Fabric it reads from a shared foundation, not from a copy nobody is quite sure of the age of.

How Dataverse links to Fabric, without ETL

The most important change for D365 customers is the link between Dataverse and Fabric. With a few clicks, either from the Power Apps maker portal or from Fabric, a shortcut is created in OneLake that points directly at your Dataverse tables.

What is striking is what does not happen: no export, no ETL pipeline, no third-party integration tool. The tables appear in a Fabric lakehouse as if they had been copied there, but it is a reference to where the data actually lives in Dataverse. The data is exposed in Delta-Parquet format, which every Fabric workload understands, so you can analyse it with Spark, SQL and Power BI without transformation.

Two things are worth noting. The shortcuts are read-only. Fabric reads from Dataverse but does not write back (this protects the source system and follows the principle that master data is refined, not changed at random). And for sources outside Dataverse, Fabric Mirroring can replicate data from existing systems continuously into OneLake with low latency.

What it looks like in practice for Dynamics 365

The abstract becomes concrete when you see what is actually being joined together. Two patterns we meet often with Dynamics 365 customers:

Sales + finance + marketing in one model

An example: a business uses Dynamics 365 Sales for pipeline, Business Central for invoicing and GA4 for website traffic. Before Fabric, the numbers lived in three separate reports. With Fabric, the sales director can see which marketing campaigns actually generated orders and margin, without manually joining three exports every week. That is Dynamics 365 reporting across sources, not three disconnected dashboards.

Service + ERP + sensor data for predictive maintenance

Service history from Dynamics 365 Customer Service combined with ERP data, IoT/sensor data and warranty data. Together it provides the basis to predict failures before they happen, not just report them afterwards. None of the sources is enough on its own; the value lies in reading them together.

In the projects we've been part of, we often see that the biggest challenge isn't connecting to Dataverse. It's agreeing on which KPIs should actually be the truth.

Direct Lake, import or DirectQuery: how Power BI reads from Fabric

Once data lives in OneLake, Power BI can read it in three ways. The choice decides both freshness and performance.

• Import. Data is copied into the Power BI model. Fastest queries, but requires scheduled refresh. The numbers are as fresh as the last refresh.
• DirectQuery. Power BI queries the source live on each view. Always fresh, but heavier on performance at large volumes.
• Direct Lake. The new, Fabric-specific mode: Power BI reads the Delta tables in OneLake directly, without import and without the classic DirectQuery penalty. You get near import-level performance with near real-time freshness, provided you have the capacity it requires.

Direct Lake is the reason many consider Fabric at all. Many organisations that need to distribute reports broadly and use Power BI Direct Lake at the same time consider F64 or higher. For smaller environments, lower SKUs work perfectly well.

The three read modes in one table

The choice between the three can be summarised like this:

What Fabric costs, and where the F64 threshold sits

Fabric is bought as capacity, not per user. Capacity is measured in F-SKUs. Guideline list prices in 2026: F2 starts around USD 263 per month, while F64 sits around USD 5,257 per month (prices vary by region and agreement). Capacity can be bought both as pay-as-you-go (PAYG) and as reserved commitments at a lower cost over time.

F64 is the threshold that matters most. On F64 or larger, users with only a free Power BI licence (and a viewer role) can view Power BI content. Below F64, every reader needs Power BI Pro. F64 is also the level many begin their assessment around for Direct Lake and multiple concurrent users. For an organisation that needs to distribute reports widely, the calculation is often F64 capacity versus the sum of Pro licences.

In other words: the real Fabric decision is rarely F2 versus F4. It is whether you need the F64 layer or not, and that depends on how many will read, and whether you want Direct Lake.

Pattern: A mid-sized organisation with around 120 Power BI readers had Pro licences for all of them. When they did the maths, the annual Pro cost was close to an F64 capacity, but F64 also gave them Direct Lake, OneLake and room for data pipelines on top. The point was not that Fabric was free; it was that they were already paying for half the platform without getting the rest.

The F-SKU ladder

The ladder looks like this, with F64 as the real threshold:

The capacity limits and the viewer threshold are documented in Microsoft's Direct Lake overview (checked August 2026). Prices are indicative list prices and vary by region and agreement.

When Fabric is right for Dynamics 365, and when it is not

Fabric is not a default choice for every D365 customer. For a smaller organisation that just needs a few dashboards on clean D365 data, the Dataverse connector in Power BI is still the simplest and cheapest route, and entirely sufficient.

Fabric starts to pay off when:

• you combine Dynamics 365 with data from ERP, web, finance or other sources in the same analysis
• the data volume or history is too large to import comfortably into Power BI
• many people need to read reports, and the F64 layer with free viewers is cheaper than Pro for everyone
• you are building towards AI and agentic CRM, where the models need one reliable data foundation
• you want to move away from legacy Synapse Link exports and scattered copies

And the opposite test matters just as much: if you cannot say which decisions the consolidated data platform is meant to support, Fabric is an infrastructure project in search of a purpose. Then you should wait.

A common observation: organisations often plan a large Fabric project before they have settled who owns the data definitions. That is when the project stalls.

We've seen that the most successful Fabric implementations start narrow (one data source, one concrete decision-support question) before they expand.

Security and governance

Fabric simplifies data access, but it does not replace access control. Data gathered in OneLake still has to be secured through roles, workspaces and governance models. A well-considered Microsoft Fabric architecture accounts for this from the start.

For organisations bringing in Dataverse data, it is important to understand that the Dynamics 365 security model is not automatically reflected in Fabric workspaces. Access to Account or Opportunity data has to be modelled again, as dataset permissions, Power BI roles or workspace access. It is one of the most important decisions in any Dataverse analytics work in Fabric.

GDPR requirements (data residency, deletion, audit trail) affect where data is stored and how it is processed. Fabric runs on Azure with region selection, but person-level deletion has to be designed into the project. It does not happen by itself.

Fabric as the foundation for AI and agentic CRM

The strategic reason to build on Fabric now is not reporting. It is what comes after. Agentic AI features in Dynamics 365 and Copilot read from data to suggest and act. An agent reading from messy, conflicting data makes messy decisions, just faster, and at greater scale.

A shared data foundation in OneLake (with Dataverse as the source and a thin refinement layer on top) is the precondition for AI on top to be trustworthy. Fabric is not AI. But it is the floor the AI stands on.

Conclusion

Power BI shows the numbers. Fabric and OneLake decide whether the numbers are worth showing. For D365 customers, the good news is that the connection is simpler than before: Dataverse links straight into Fabric, without ETL. The hard part is not technical. It is knowing which data to gather, who will read it, and which decisions it should carry.