TL;DR
Link to Fabric and Azure Synapse Link are not two flavours of the same service. In Microsoft's own comparison one keeps the data in Dataverse and consumes Dataverse storage, while the other exports to a storage account you own, and — on the delta-parquet profile Microsoft documents for finance and operations tables — needs a Synapse workspace and Spark pool to convert it. This is what each requires before it works, Microsoft's cost and freshness figures with the caveat Microsoft attaches to them, the one-way doors documented on each side, and the live networking dispute sitting under one of the two.
Fabric link or Synapse Link — which analytics path for Dynamics 365 data?
They are not two flavours of the same service. One keeps your data inside the Dataverse governance boundary; the other exports it to a storage account you own. The choice sets your cost model, your security boundary, and several things you cannot undo without a full resync.
The difference is a billing model and a boundary, not a feature list
Both are generally available with finance and operations data [GA], and both end in delta parquet. That framing hides the decision.
Link to Fabric creates shortcuts from Dataverse into Microsoft OneLake: "There's no need to provide a storage account or Synapse workspaces … the system creates an optimized replica of your data in delta parquet format … using Dataverse storage" (Microsoft Learn, ms.date 2026-07-06).
Azure Synapse Link "continuously exports data from Dynamics 365 and Power Apps to your own storage account" (Microsoft Learn, ms.date 2026-07-23).
Microsoft's own four-line comparison, transposed so the row label is the dimension rather than the product — content Microsoft's, row axis ours:
- Integration style — Link to Fabric: "No copy, no ETL direct integration with Microsoft Fabric" · Azure Synapse Link: "Export data to your own storage account and integrate with Synapse, Microsoft Fabric, and other tools"
- Where the data sits — Link to Fabric: "Data stays in Dataverse - users get secure access in Microsoft Fabric" · Azure Synapse Link: "Data stays in your own storage. You manage access to users"
- Table selection — Link to Fabric: "All tables chosen by default" · Azure Synapse Link: "System administrators can choose required tables"
- What it consumes — Link to Fabric: "Consumes additional Dataverse storage" · Azure Synapse Link: "Consumes your own storage as well as other compute and integration tools"
Row three is the one architects underweight, and two Microsoft pages disagree about it. Selecting the Fabric link "adds all nonsystem Dataverse tables that have the Track changes property enabled". The transition FAQ (ms.date 2026-07-23) says: "You can't remove these tables as some of these tables might be used by Dynamics 365 as well as partner applications and removing them can cause the applications to fail."
The Link to Fabric how-to (ms.date 2026-07-06) documents the opposite — a standalone Manage tables surface, with "You can change this selection any time after setup" and "Clear any tables you don't want to sync" — excepting only "some system tables and tables required by Microsoft add-ins".
Until one page moves, treat table-level control on the Fabric side as documented but contested. We are not resolving it here, and neither page is newer by enough to settle it.
What each requires before it works
This decides your calendar, because both paths fail at a prerequisite rather than at a query.
- Identity you need — Link to Fabric: System Administrator in the environment, plus Power BI workspace admin · Azure Synapse Link: System Administrator in the environment
- Licence or capacity — Link to Fabric: "A Power BI premium license or Fabric capacity within the same Azure geographical region as your Dataverse environment is required" · Azure Synapse Link: An Azure subscription
- Azure resources you provision — Link to Fabric: None — the system uses Dataverse storage and compute · Azure Synapse Link: Azure Data Lake; plus an Azure Synapse workspace and Spark pool on the delta-parquet profile. Microsoft's incremental-CSV profile needs the data lake only
- Tenant switches — Link to Fabric: Fabric admin settings for creating items and workspaces, plus external OneLake access · Azure Synapse Link: None on the two Azure Synapse Link pages cited here
- Profile constraint — Link to Fabric: "Today, a Dataverse environment links to a single Fabric workspace"; support for multiple links is
[PLAN]· Azure Synapse Link: "You can't add finance and operations data to an existing storage account that's configured with Azure Synapse Link"
Two rows have teeth. The capacity requirement is regional, not just commercial: with no Fabric capacity in your Dataverse environment's geography, "the wizard notifies you to get a capacity in the required geography."
And on the Synapse side, "Finance and operations table selection isn't visible if your Synapse Link profile isn't configured for Delta lake."
What each costs, in Microsoft's own figures
Microsoft attaches a caveat to every number below, and it belongs above them:
"These estimates are provided to enable estimating the spend after transition. While these estimates are based on experience from preview customers, actual costs incurred in your environment as well as data compression can vary depending on volume and composition of data." — Transition from legacy data integration services (ms.date 2026-03-30)With that in place:
- The recurring charge — Link to Fabric: An increase in Dataverse database storage, drawn against a quota "based on the number of licenses you purchased" · Azure Synapse Link: A Spark pool "to convert data to Parquet format", plus your own storage and integration services
- Microsoft's monthly Spark ranges — Link to Fabric: Not published as a range · Azure Synapse Link: Small to medium change volume: "$600 to $2,000 for hourly refresh"; "$1,200 to $4,100 for 15-minute refresh". Medium to large: "$1,200 to $2,500" and "$2,500 to $8,300"
- The sizing rule Microsoft gives — Link to Fabric: "if you sync 500 GB of data from Dynamics 365, Dataverse storage could increase by around 100 GB (assuming five to eight times data compression)" · Azure Synapse Link: You size the storage account and the pool
- What happens when you want it fresher — Link to Fabric: Compute is "factored into Dataverse storage" · Azure Synapse Link: Cost rises with refresh frequency — the ranges above are the same volumes at two intervals
That last row is the real comparison. On the Synapse side freshness is a dial with a published price: "The lower the time interval, the more compute resources are consumed and you can incur more cost." The Fabric pages document no equivalent setting — cheaper to run, less to tune.
How fresh each is, and the caveat that matters most in supply chain
Neither is real-time. Microsoft's figures:
- Documented update window — Link to Fabric: "It might take up to 60 minutes for the data to be refreshed especially during peak load periods" · Azure Synapse Link: Delta conversion interval you set: "enter 5, 15 or 60 minutes"; 1440 for daily
- Microsoft's observed range — Link to Fabric: "Dataverse triggers data update jobs every 15 minutes and depending on the volume of data changes, you might see updated Parquet files within 15 to 45 minutes" · Azure Synapse Link: "the actual data refresh observed in the lake could be more than 15 minutes" at a 15-minute setting
- New engine — Link to Fabric: Low-latency sync
[GA]— no preview marker on the page, described as rolling out by station — "up to 1M or more records per hour per table" for finance and operations tables · Azure Synapse Link: Not applicable
Microsoft then names our exact workload as the case where those numbers stop holding:
"In situations with high transaction volumes, such as processes in Dynamics 365 finance and operations apps generating millions of records in a short time, or processes like the master planning feature included with Dynamics 365 Supply Chain Management that delete and re-create large volumes of records, Synapse Link must synchronize all changes including deletes. In these high-volume scenarios, data availability within the indicated timeframes can't be guaranteed."
If your planning run rebuilds planned orders nightly, that sentence is about you. Quote any freshness promise against the night master planning runs, not against a quiet Tuesday.
What the choice locks in
Both paths have one-way doors — these are the ones documented on the pages above.
- CSV profiles can't reach Fabric — Which side: Synapse · What Microsoft says: "Existing Azure Synapse Link for Dataverse profiles where the data is saved as CSV files can't be linked to Microsoft Fabric"
- Managed-identity profiles can't reach Fabric — Which side: Synapse · What Microsoft says: "Currently, Azure Synapse Link profiles secured with managed identities, formerly Managed Service Identity (MSI), can't be linked to Microsoft Fabric"
- Moving to the new engine forces a full resync — Which side: Fabric · What Microsoft says: "Unlinking and relinking triggers a full initial sync for all configured tables"
- The timestamp format changes underneath you — Which side: Fabric · What Microsoft says: "Low-latency sync writes timestamp columns as INT64. The INT96 timestamp format used by the previous Fabric link sync engine isn't supported"
- Retained data drops out of the shortcuts — Which side: Fabric · What Microsoft says: After relinking, "the shortcuts include live data only", and reporting on retained data through Fabric "isn't available for those tables"
Row two deserves a second read. Microsoft states you can also secure the storage account with firewalls and restrict access via managed identities, and separately that managed-identity profiles currently can't be linked to Fabric.
Joining those two sentences is ours, not Microsoft's — neither page makes the connection. The consequence is real: the secure choice on one path narrows the options on the other.
The live risk sitting under the Synapse side
This belongs in the comparison, because leaving it out would flatter one option.
The Synapse path reaches a storage account you own, and where that account is firewalled the connection has rested on a trusted-services exception. Microsoft's transition FAQ, ms.date 2026-07-23, still says in the future tense that this exception "will be retired on 1 August 2026" — today. A Microsoft Q&A thread, answered on 9 July 2026 by a moderator badged Microsoft External Staff, says the retirement "has been postponed" into 2027. That is a support thread, not a revision to the documentation.
Documentation and tenant notification disagree, and we set out all twelve sources separately. Status is [DEPR] with the date itself in dispute.
Two consequences. Do not resolve it from a blog: open the Azure portal, go to Service Health, and read the notification sent to your subscription.
And price the remediation first — Microsoft's documented step one is "Create a Synapse workspace with a managed virtual network" — and Microsoft's managed virtual network page states "You can't change this workspace configuration after the workspace is created… you can't reconfigure a workspace that doesn't have a Managed workspace Virtual Network associated with it and associate a Virtual Network to it."
So on some estates the fix is a new workspace rather than a setting.
The Fabric path carries no equivalent exposure on these five pages, and the reason is structural in Microsoft's own description of it: no storage account of yours is in the path to firewall.
Which one for which job
Microsoft's steer is short: "If your organization is already using Fabric or planning to transition in the coming months, we recommend using the Fabric link feature. You can continue to use the Azure Synapse Link service if your immediate focus is to upgrade from your current services." Ours is narrower, and it is opinion rather than documentation:
- Power BI is already the consumption layer — Take: Link to Fabric · Why: You are paying for capacity anyway, and the storage account and Spark pool disappear from your estate
- Non-Microsoft software reads the data — Take: Azure Synapse Link · Why: Your own storage account is the point; delta parquet is readable by anything
- You feed a downstream warehouse incrementally — Take: Azure Synapse Link · Why: The incremental profile writes CSV into time-stamped folders and needs no Spark pool at all
- You have thousands of active Dataverse tables — Take: Azure Synapse Link · Why: "If you have more than 2,000 active Dataverse tables, Link to Fabric can fail with an error"
- You need a documented, uncontested guarantee of which tables leave — Take: Azure Synapse Link · Why: The Fabric side currently has two Microsoft answers — the transition FAQ says the auto-selected set can't be removed, the Link to Fabric how-to documents a Manage tables surface
- Nobody owns the pipeline in a year's time — Take: Link to Fabric · Why: The cheapest infrastructure is the kind you never provisioned
We would argue hardest for the last row. An analytics path needing a Spark pool tuned by somebody who has left is cheaper only in the quarter you built it.
Where we would draw the line
We would not make this choice for you. It sets your Azure spend, your security boundary and your reporting estate for years, and it belongs to your data team and your implementation partner.
We would not read an optimizer's live inputs from either path. Both are analytical copies on a refresh interval set in minutes — right for training a model, wrong for the state a decision acts on. That read goes through a supported transactional surface, which is the pillar this article sits under.
And we would not quote a business user a freshness number from either page without asking when their master planning runs. Microsoft has already said the guarantee lapses at exactly that volume.
What we own is the decision on top. An Optimizer trains on this history and optimizes the call — the safety-stock level, the margin-optimal price — then writes it back behind a human approval step. Dynamics 365 stays the system of record; the optimizer is the system of intelligence beside it, and only ever as current as the path underneath it.
About Cognilium Cognilium is the AI optimization layer for Dynamics 365 — complementary apps that optimize the pricing, inventory, warehouse and planning decisions your ERP manages but can't optimize. Built on Power Platform, Dataverse and Azure. https://cognilium.ai · https://www.linkedin.com/company/37180269/
If an Optimizer of yours will train on Dynamics 365 history, the analytics path underneath it sets both its accuracy and its running cost. Book a fifteen-minute call and we will walk both paths against your estate — which surface, how fresh, what it locks in. No deck. https://cognilium.ai
Sources
- Choose finance and operations data in Azure Synapse Link for Dataverse
- Configure your environment and link to Microsoft Fabric
- Link your Dataverse environment to Microsoft Fabric
- Transition from legacy data integration services to Fabric link and Azure Synapse Link
- Azure Synapse Link transition FAQ
- Microsoft Q&A thread — the workspace-level opt-in setting and the trusted-services retirement date
- Managed virtual network (Azure Synapse Analytics)
Sources
- learn.microsoft.com — azure synapse link select fno data
- learn.microsoft.com — fabric link to data platform
- learn.microsoft.com — azure synapse link view in fabric
- learn.microsoft.com — azure synapse link transition from fno
- learn.microsoft.com — azure synapse link transition faq
- learn.microsoft.com — does the new workspace level opt in setting defaul
- learn.microsoft.com — synapse workspace managed vnet
Share this article
Muhammad Mudassir
Founder & CEO, Cognilium AI
Muhammad Mudassir
Founder & CEO, Cognilium AI
Mudassir Marwat's argument is that ERP systems record decisions they never optimise.
