Integrating Dataverse with Microsoft Fabric: Link to Fabric for near-real-time analytics

Link to Microsoft Fabric is the feature that takes Dataverse tables, including the Dynamics 365 Sales, Customer Service, and Field Service tables that live in Dataverse, and makes them queryable in Fabric without exporting anything. It is the successor in spirit to Synapse Link, and for most organisations already on Fabric it is now the default route for Dynamics 365 CRM analytics. It is worth understanding precisely what it does, because "no copy" and "real time" are both true in a specific sense and misleading in a general one.

What Link to Fabric actually does

You link a Dataverse environment to a Fabric workspace from the Power Apps maker portal. Dataverse then maintains a Delta Lake representation of the selected tables in Dataverse-managed storage, and Fabric exposes that as a Lakehouse with shortcuts pointing at it. Analysts see tables in a Fabric Lakehouse; Power BI sees them through Direct Lake; the SQL analytics endpoint lets you query them with T-SQL. Nothing is copied into OneLake, and nothing needs an Azure subscription or a storage account of your own.

The distinction from Azure Synapse Link for Dataverse: Synapse Link writes to an ADLS Gen2 account you own and is the right choice when the destination is not Fabric, or when you need the files under your own control for other consumers. Link to Fabric keeps the data in Dataverse's storage and counts against Dataverse capacity. If Fabric is the warehouse, Link to Fabric is simpler. If Snowflake or Databricks is the warehouse, Synapse Link is the one you want.

What "near real time" means here

Changes in Dataverse appear in the Fabric Lakehouse after a refresh interval that is typically minutes, not seconds, and it varies with load and table size. That is close enough for operational dashboards that refresh every quarter of an hour. It is not close enough for anything that reacts to a single record change, and it is not an eventing mechanism. If you need to act on a record within seconds of it changing, that is a job for webhooks or Dataverse events, not for analytics.

For genuinely streaming needs, Fabric's Real-Time Intelligence workload (Eventstreams and KQL databases) can ingest from Dataverse change events via Event Hubs or Service Bus, but you are then building an eventing pipeline, and Link to Fabric is not part of it.

Patterns that work

Direct Lake reports on Dataverse tables. The headline use case. Power BI semantic models over the linked Lakehouse tables, with no import refresh and no DirectQuery latency. Sales pipeline, case backlog, and work order dashboards land here. Keep the semantic model over a curated layer rather than the raw tables, because raw Dataverse tables carry option set integers, GUID lookups, and a hundred columns nobody wants.

Cross-system models. Dataverse tables joined with Finance and Operations data (also linkable to Fabric) and with external sources landed in the same Lakehouse. This is where Fabric earns its place over a plain Power BI model: a customer 360 that spans CRM opportunities and ERP invoices without a custom integration.

Notebooks and data science. Spark over the linked tables for churn scoring, lead scoring, or forecasting, with results written to a separate Lakehouse table and surfaced back into Dynamics 365 through a virtual table or a scheduled Dataverse write. Never write model outputs back into the linked tables; they are read-only from the Fabric side by design.

Historical retention. Dataverse has no cheap way to keep years of closed cases or won opportunities queryable. A Fabric Lakehouse fed by Link to Fabric, with a periodic snapshot into a separate archive table, becomes the long-term store, and bulk delete jobs can then trim Dataverse.

Capacity and cost

Two meters run. Dataverse storage capacity grows because the Delta representation is stored on the Dataverse side. Fabric capacity units are consumed by whatever you run in Fabric: Direct Lake queries, Spark notebooks, SQL endpoint queries. Neither is dramatic for a mid-sized CRM, but both surprise organisations who assumed "no copy" meant "no cost". Check the Dataverse storage types guide for how the Dataverse side is counted.

Security

Dataverse row-level and column-level security do not apply in Fabric. A user with access to the Lakehouse sees every row of every linked table. Fabric's own OneLake security and semantic model row-level security are where access control gets rebuilt. This is the single most common design gap: a CRM where sales territories carefully hide each other's opportunities, feeding a Fabric workspace where everyone sees everything.

What breaks in practice

Table selection creep. Someone links every table "to be safe" and Dataverse capacity climbs. Link what reports need.

Schema changes. New columns appear automatically; deleted columns and renamed tables are handled less gracefully. Downstream notebooks that hard-code column lists break.

Environment lifecycle. Restoring or copying a Dataverse environment does not carry the Fabric link. Rebuild it as part of your environment runbook.

Expectation management around latency, as above. Label dashboards with their refresh time.

Stability verdict

Link to Fabric is generally available, actively invested in, and clearly Microsoft's preferred path, so it is a safe foundation. The moving parts are around it: Fabric's own workloads change quickly, and the capacity model is still being tuned. For the wider picture of where Fabric fits across Dynamics 365, including F&O and Business Central, read Microsoft Fabric and Dynamics 365.