Insights · Data and analytics
This page describes the data path: which link Microsoft still offers today, what is replicated and what is not, how the layers are sensibly cut for CRM data — and why your Dataverse permission model ends at the boundary to the lakehouse. As of 06.11.2026, based on the Microsoft documentation. What we take on from this is described on the service page for Microsoft Fabric for Dynamics 365 and Dataverse.
The data path
For a link in an environment that has never had one, there is exactly one path today. That is not a simplification but a product decision by Microsoft: the Delta Lake output of Azure Synapse Link has been unavailable to new customers since 15 October 2026, and profiles with CSV output cannot be linked to Fabric. Eligibility is assessed per Dataverse organization ID rather than per tenant — a new environment with a new organization ID is never eligible. Anyone who changes environment during a migration project loses eligibility for Azure Synapse Link.
Dataverse creates a lakehouse, a SQL analytics endpoint and a Power BI semantic model in your Fabric workspace and links the selected tables by shortcut. You provide neither a storage account nor a Synapse workspace.
email, activitypointer and activitymimeattachment.The path into your own Azure Data Lake Storage Gen2. Existing customers must switch to CSV output or to Link to Fabric by December 2027 . An eligible existing organization may unlink and re-link for the same organization ID. In Power Apps the interface is now called Link to Data lake.
Fabric Mirroring replicates source systems continuously into OneLake — with database and open mirroring, changes can be published every 15 seconds, and one terabyte of mirroring storage is free per capacity unit purchased. For Dataverse it is still not a path: the documented source list includes Azure SQL, Cosmos DB, PostgreSQL and MySQL, Databricks, BigQuery, Oracle, SAP, SharePoint lists, Snowflake, SQL Server, Dremio and Open Mirroring — Dataverse and Dynamics 365 are not in it. Two qualifications belong with that: some of these sources are marked as preview, and some work as metadata mirroring, which replicates no data.
Replication behavior
null; historical values remain in rows that have not been updated since the deletion.documentbody are not exported. Anyone expecting document contents in analytics will not get them on this path — the metadata of the attachment tables comes along, the binary contents do not.bot, workflow, flowmachine and desktopflowmodule. Installed Microsoft add-ins extend this mandatory set.The most important point for every analysis that counts records is deletion behavior. In append-only mode, the current version of a record is not the last row but the one with the highest VersionNumber and SinkModifiedOn — together with the filter isDeleted=0. Without that step, every report counts history as current stock. Hard deletion follows after 30 days; anyone who needs deleted records for longer enables long term data retention. Deletions issued by a direct SQL call do not trigger the service, because BPO.Delete is not called — those rows remain in the lake although they are gone in Dataverse.
Architecture
Microsoft names the medallion architecture as the recommended design: bronze as raw data, silver as enriched, gold as curated data — and explicitly recommends keeping each lakehouse in its own workspace , because workspace roles apply across all items. Bronze, silver and gold in the same workspace means: a contributor sees the raw data.
Bronze with Link to Fabric is the lakehouse managed by Dataverse — a read surface only. Two things about it: the name follows the pattern <environmentname>_<internalprofile>_<workspace>_<uniquevalue>, and Microsoft explicitly warns against relying on it in code, queries or pipelines; references go through workspace and lakehouse ID. And: unlinking deletes the lakehouse — and fails as long as other Fabric items reference it. Before a planned re-link, the dependency list should be cleared through the lineage view.
Silver is the layer with the most benefit per unit of effort, because it smooths exactly the peculiarities of the raw Dataverse data. Deduplicate to the current record version and filter out deleted rows; resolve choice columns against their labels — the metadata tables OptionsetMetadata and GlobalOptionsetMetadata supply the labels, and their schema changed with the low latency engine, where the column createdonpartition is missing; join lookups to readable names; model business unit, owner and team as real dimensions, because those are exactly what the access model in Fabric needs. One trap at the end: earlier Fabric links converted empty SQL strings to NULL , while the low latency engine keeps the empty string. Anyone checking for IS NULL is checking against nothing after the switch.
Gold holds the tables a business unit can read without asking back. Microsoft explicitly names gold as the ideal use case for Direct Lake: the semantic model loads columns directly from the Delta tables in OneLake, the refresh copies metadata only and takes seconds instead of a full import. On file layout, because it determines cost: target file sizes between 128 MB and 1 GB, smaller files in bronze and larger files with larger row groups in gold; for silver and gold, Microsoft recommends liquid clustering instead of partitioning.
The technical heart of it
The row and field level security you have built in Dataverse does not automatically carry over into Microsoft Fabric. Anyone who does not know this builds a data leak — with correctly configured products and without a single error message.
The link reads with the identity you give it — not with that of the report reader. Link to Fabric authenticates through workspace identity, service principal or organizational account. For the first two, Microsoft requires the identity to be added as an application user in Dataverse and given a suitable role. What ends up in the replica is therefore the read scope of that identity, not that of the later report reader.
Fabric does not know the Dataverse model. OneLake separates a control plane — workspace roles, item permissions — from a data plane with OneLake security, row and column level security. Business units, security roles, access teams and record ownership from Dataverse exist in none of these planes.
The upper workspace roles see everything. Admin, member and contributor already have read and write access to all data in a workspace and are not restricted by OneLake security roles. Anyone who gives someone the contributor role just quickly cancels the row model.
Direct Lake on OneLake does not apply SQL-based row-level security. If the SQL analytics endpoint enforces row-level security, queries on Direct Lake on OneLake still run through successfully, and the SQL-based row-level security is not applied. In this constellation, security belongs in the semantic model or in OneLake security, not in the SQL endpoint.
Column-level security works, but differently than expected. With Azure Synapse Link, the application account Dynamics365Athena2reads. If a column is secured and the account is not in the matching profile, synchronization runs through successfully and the column is exported as null — a silent empty column in the report, not an error.
Technically it also holds that row and column level security work on Delta Parquet tables and on virtualized Iceberg tables. For other table types, access to the entire table is blocked, not filtered — that is a design specification, not a side note.
DefaultReader to be checked. In every lakehouse there is a role called DefaultReaderthat gives every user with ReadAll access to the data. It can be edited or deleted. Anyone who leaves it in place without knowing about it has a door open that they did not build.Scope note: An access model built this way is a technical configuration. It carries no statement about whether a data processing operation as a whole meets regulatory requirements — that is a legal assessment.
Data residency
Two statements from the Microsoft documentation belong together, because each on its own gives the wrong picture. The first: capacity and workspace no longer have to be in the same Azure region as the Dataverse environment. Read on its own, that sounds like data leaving. The second: the replica stays in the same region as your Dataverse environment and is managed and secured by Dataverse.
Together this means: the replica does not travel, the place of processing and reporting can. Added to that are two switches to be decided separately — encryption at rest with Microsoft-managed or with customer-managed keys, and logging: OneLake diagnostics for data access, Fabric audit logs for control operations.
On the network side, the following currently applies to Link to Fabric: inbound workspace access must allow all networks; workspaces that use private endpoints exclusively are not supported. Outbound, public access can stay blocked if a data connection rule allows the URL of the Dataverse environment.
Capacity
Fabric capacities are Azure resources and are billed by the second with a one-minute minimum. They are obtained either through an Azure subscription or through a Cloud Solution Provider. A capacity reservation over one or three years lowers the price; both terms cost the same per year.
Two price points determine the architecture decision: the entry at F2 at €288.35 per month pay-as-you-go, or €171.46 reserved, and the threshold at F64 at €9,227.20 or €5,486.78 respectively. The complete SKU table, all Power BI licensing models, non-profit and education rates and the break-even calculation are on our page about Power BI licensing, pricing and discounts. As of: Azure retail prices Western Europe, 06.11.2026; calculated with €0.1975 per capacity unit and hour and 730 hours per month. Net. The reservation saving of 40.54 % is calculated from the two Azure prices; Microsoft does not state a percentage.
On F SKUs below F64, every user who only wants to view Power BI content needs a Pro, PPU or trial license. From F64 upwards, users with a free Microsoft Fabric license and the viewer role in the workspace may read. Authors need Pro or PPU in every case in order to publish Power BI items outside their own workspace. Non-Power-BI items — lakehouse, warehouse, notebook — can by contrast be created and shared with the free license if the workspace sits on an F or trial capacity.
These limits belong here and nowhere else, because they determine the architecture and not the purchase:
| SKU | Files / row groups per table | Rows per table | Model size | Memory |
|---|---|---|---|---|
| F2 / F4 / F8 | 1,000 / 1,000 | 300 million | 10 GB | 3 GB |
| F16 | 1,000 / 1,000 | 300 million | 20 GB | 5 GB |
| F32 | 1,000 / 1,000 | 300 million | 40 GB | 10 GB |
| F64 | 5,000 / 5,000 | 1.5 billion | unlimited on OneLake | 25 GB |
Up to F32, files, row groups and rows therefore stay unchanged — only model size and memory grow. If the limits are exceeded, the refresh on Direct Lake on OneLake fails and the model cannot be queried until the Delta tables are optimized; Direct Lake on SQL falls back to DirectQuery instead, unless fallback is switched off.
Pausing stops the compute meters of all Fabric workloads. The OneLake storage meter keeps running — storage is paid for even with a paused capacity. On pausing, remaining cumulative overages and smoothed operations are summed up and added to the Azure bill; a pause is therefore not a reset. Pausing can make Fabric content unavailable, and with a paused capacity, mirroring does not replicate. One side effect that speaks for it: if a capacity is throttled, pausing ends the throttling immediately.
The reservation discounts by the hour. Anyone not running a matching resource in a given hour loses that hour's reserved amount; there is no carry-over. Storage and networking are not covered by the reservation. Practical consequence: pausing is a lever for development and test capacities billed pay-as-you-go. A reserved production capacity that is shut down overnight on a schedule pays the reservation through and does not use it.
Existing estate
Power BI. Reports and semantic models do not have to be replaced. Import and DirectQuery models stay valid; OneLake integration additionally writes tables in import mode as Delta tables into OneLake — without migration effort. The switch happens where Direct Lake actually brings something: on the gold layer, with large volumes, with requirements on data freshness. Two things only become apparent late: Direct Lake does not support complex Delta column types, nor Binary and GUID — with Dataverse, GUID affects every primary key and every lookup. And a Direct Lake semantic model can only be created in the same region as the workspace of the data source.
Power BI Premium. Microsoft is retiring the Premium capacity SKUs; new and existing customers are to consider F SKUs. P SKUs are only available to customers with an active Enterprise Agreement, and Power BI EM SKUs do not support Fabric.
SQL Server is a documented mirroring source. An existing data warehouse can be mirrored into OneLake and joined with the Dataverse data in the same query — Fabric allows cross-database queries across mirrored databases, warehouses and SQL analytics endpoints in a single T-SQL statement.
Azure Synapse Analytics is the case with real pressure to act. The Delta Lake output is being retired, and the low latency engine of Link to Fabric writes with newer Delta Lake capabilities, including deletion vectors — which Synapse serverless SQL pools do not support in all scenarios. Anyone running reports over serverless SQL today moves the load to the Fabric SQL analytics endpoint or rewrites the tables into their own lakehouse through a notebook — the latter costs compute time, planning and latency and is the second choice. The situation becomes manageable through an inventory of downstream consumers, a target path per consumer and an order in which nothing goes dark. See also Migration.
Questions and answers
Link to Fabric — and only that one. Why there is no second one and how eligibility is assessed per Dataverse organization ID is explained in the section on the data path.
No. Business units, security roles, access teams and record ownership are Dataverse concepts. What applies in Fabric instead, and which three traps strike while doing it, is explained in the section on permissions.
No — Dataverse and Dynamics 365 are not in Microsoft's documented source list for mirroring. Which sources are in it is named in the section on the data path.
From F64. Below that, everyone who only wants to view Power BI content needs a Pro, PPU or trial license. The further SKU limits are in the section on capacity.
Next step
What we deliver in doing so, in which building blocks and with which result, is described on the service page. Would you rather talk directly? In the architecture conversation we go through your environment.