D365Forge

Catalogue › Data and AI › fabric-link

Fabric link and Azure Synapse Link

Department
Data and AI
Stages
Initiate, Implement, Operate
Modules
All
Status
reviewed
Copilot Cowork
Data and AI plugin for Copilot Cowork, or this skill on its own: Download SKILL.md
Claude Code
/plugin install data-and-ai@d365forge
Licence
CC BY 4.0, by Simon Foote, Robert Peledie

Sooner or later someone wants CRM data next to ERP, web and telephony data, or wants years of history that would overwhelm a DirectQuery report. Microsoft's routes for this are the Link to Microsoft Fabric feature and Azure Synapse Link for Dataverse, which replaced older export services. Check current Microsoft Learn documentation for naming, options and limits before advising, because this area changes quickly.

Projects go wrong by enabling a link because the wizard makes it easy, then discovering that people in the analytics workspace can see rows the CRM security model hides, that storage consumption has grown, and that nobody owns the pipelines built on top.

When to use

Not this skill: data-and-ai:power-bi-on-dataverse for reporting directly on Dataverse, data-and-ai:reporting-strategy for choosing the reporting tier, marketing:customer-profile-unification for unified customer profiles in Customer Insights - Data, integration-and-data:integration-architecture for operational interfaces.

Questions to ask first

  1. What need does this serve that Power BI on Dataverse cannot? If there is none, do not add a data platform.
  2. Does the organisation already have Fabric capacity or an Azure data platform, in the same region as the Dataverse environment? Existing platforms and regional constraints usually decide the route.
  3. Must the organisation own the storage and files, for example for its own tools, network controls or retention? That points toward Azure Synapse Link to its own storage account.
  4. How fresh must analytical data be? Both routes are near real-time rather than instant; check current Microsoft Learn documentation for expected latency.
  5. Who may see the data once it is outside the app? This is a security design question before it is a technical one.

Approach

Choose the route.

  1. Link to Microsoft Fabric. Dataverse maintains an analytics-ready copy of selected tables in Dataverse-managed storage and exposes it to a Fabric workspace through shortcuts, so there is no export pipeline to build. It consumes Dataverse storage capacity and needs Fabric capacity in a matching region. This is the default when Fabric is already the organisation's analytics platform. Check current Microsoft Learn documentation for prerequisites and for how many workspaces an environment can link to.
  2. Azure Synapse Link for Dataverse. Dataverse exports continuously to the organisation's own Azure Data Lake Storage account, as CSV or in Delta format with a Spark pool, optionally attached to a Synapse workspace. Choose it when you need control of storage, network restrictions or non-Microsoft tools. You own the storage, the compute and their cost.
  3. Neither. For modest volumes and CRM-only reporting, stay with Power BI on Dataverse.

Then design the link:

  1. Tables. Linked tables need change tracking enabled. Choose tables from the report catalogue, not everything available, and review the list whenever new tables are added to the solution.
  2. Layers. Treat linked tables as raw. Build curated tables that resolve choice labels and lookups, normalise currency and time zones, and handle deleted rows, then build reporting models on the curated layer. Reports should never query raw tables directly.
  3. Security. Do not assume Dataverse security roles filter what workspace or storage users see; design access as if they do not. Restrict raw data to the data engineering team, publish curated data by role, exclude or mask columns that are field-secured or sensitive, and apply row-level security again in semantic models.
  4. Deletion and retention. Understand how each route represents deleted rows and how long it keeps them. An erasure request or retention rule must reach the lake and every downstream copy, not only Dataverse; the organisation's DPO or legal adviser confirms which obligations apply.
  5. Environments. Link each environment to its own workspace or storage. Never link a sandbox to a production analytics workspace. Solution deployments that change table schemas must be tested against downstream pipelines.
  6. Operation. Monitor link status and table sync errors, Dataverse storage consumption, and Fabric or Azure cost, with a named owner for each.

Outputs

Scale notes

SMB

Usually not needed at go-live; Power BI on Dataverse covers most needs. If the organisation already uses Fabric, the Fabric link is the lowest-effort route, but still choose tables deliberately and restrict workspace access. Do not skip the security design because the setup is a wizard.

Enterprise

A data platform team typically owns Fabric or Azure, with the CRM programme as a supplier of data. Agree a contract for table schemas and change notice, shared curated layers with other domains, data governance through the organisation's catalogue and sensitivity labelling, and separate links per environment aligned with release management.

Hand-offs

Sources

references/sources.md in this skill lists the outside authorities for the questions here, what each is authoritative for, and what you may do with it. Check the current Microsoft Learn documentation before stating how a feature behaves, because Dynamics 365 changes monthly, and cite what you used.

Never

Sources for this skill

Dynamics 365 Customer Insights - Data documentation

Microsoft Copilot Studio documentation

Microsoft Dynamics 365 licensing resources

Microsoft responsible AI principles and practices

Power BI documentation

Credit

This skill was created by Simon Foote and Robert Peledie as part of D365Forge, licensed under CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/). Credit them when you share or adapt it; see https://github.com/SimonFoote-greensparx/D365Forge/blob/main/NOTICE.md.