A Fabric-enabled, AI-ready data strategy
Microsoft Fabric is where Dynamics 365 data becomes usable by something other than Dynamics 365. For Finance & Supply Chain Management and Business Central, it turns scattered ERP tables into a governed foundation that reporting, Copilot and AI agents can all read from. The hard part is not connecting it. It is deciding what to connect, and what that decision commits you to.
What the foundation has to serve
Finance & Supply Chain Management
Tables, not entities, once they reach the lake.
Business Central
A different data layer, and the difference matters.
Dataverse
Where the managed OneLake copy actually lives.
Two ways data moves, and they are not alternatives
Every Dynamics 365 estate ends up using both. Choosing between them is the wrong question; knowing which job belongs to which is the right one.
OData and the integration APIs
Send it for one thing and it goes and gets it, now. It is the only one of the two that can carry something back in — a new invoice, an approved order, a corrected record. That is its real job.
What it cannot do. It runs on the ERP's own capacity, and it has a trip limit. Real-world figures for this path land in the order of a thousand records an hour for a product feed and a few thousand for a status lookup. Ask it to carry the whole estate and it does not just get slow — it consumes the service protection budget that the people using the ERP are also drawing on.
Why OData slows down at a few thousand records an hour →Link to Microsoft Fabric
A continuously maintained reflection of the warehouse, kept beside it. You can run the heavy machinery against the reflection — reporting, modelling, Copilot, agents, a forecast that reads years of history — and the people working in the warehouse never feel it.
What it cannot do. It is read-only. Nothing goes back in through the mirror, which is why the courier never retires. And precisely: this is not a second warehouse you own a copy of. Dataverse keeps the managed store and Fabric is given shortcuts into it, so the data never leaves the Dataverse governance boundary.
Fabric link or Synapse Link: which analytics path →The one thing the mirror does not copy
The locks. Row-level security does not carry across, so the reflection shows every legal entity and every cost price to anyone who can reach it, whatever the ERP would have shown them. Rebuilding that access model is part of the work, not a follow-up task.
Does row-level security carry into Fabric? →What “AI-ready” actually means for ERP data
Four properties. A data estate missing any one of them will still answer a question — it will just answer it differently depending on who asks and when.
Connected
One governed copy of the ERP data, not six extracts drifting apart on six schedules. Every downstream thing — a report, a Copilot answer, an agent, a forecast — reads the same numbers on the same day.
Modelled
Business meaning, not raw table names. An ERP stores what happened in the shape the transaction needed; analysis needs it in the shape the question needs, and something has to do that translation deliberately.
Governed
Who may see which rows, decided once and enforced where the data actually lives. This is the part that most often arrives as an afterthought, and the one section below explains why that is expensive.
Traceable
Lineage from a number on a dashboard back to the ERP record it came from. Without it, nobody can audit an AI answer, and an answer that cannot be audited will not be trusted with a decision that matters.
Link to Fabric, or Azure Synapse Link?
Microsoft retired four separate ways of getting ERP data out and replaced them with two. The choice is mostly about who owns the storage.
| Your situation | The path | Why | Status |
|---|---|---|---|
| You already run Fabric, or will within months | Link to Microsoft Fabric | No copy and no ETL — Dataverse keeps a managed OneLake store and shortcuts it into your lakehouse. Direct Lake reporting on top. | Generally available |
| You need the data in your own storage account, or in non-Microsoft tools | Azure Synapse Link for Dataverse | Delta-Parquet written into an ADLS Gen2 account you control, with firewall and managed identity supported. | Generally available |
| You need an incremental change feed into a downstream warehouse | Synapse Link, incremental update folders | Timestamped folders, with an interval as low as five minutes. The direct successor to Export to Data Lake change feeds. | Generally available |
| You are still on Data Export Service | Migrate | Long dead and superseded by Synapse Link. This is not a choice that is still open. | Deprecated |
Both are generally available. Neither is a migration you want to do twice, which is what the next section is about.
What it commits you to
Connecting Fabric to Dynamics 365 is an afternoon. These are the things that are permanent, invisible or disputed, and they are the reason the afternoon is not the project.
The lake does not carry your ERP security
Extensible data security policies are bypassed for the Synapse Link service. Row-level security does not travel. Anyone with lakehouse access can see every legal entity, every cost price and every salary line in an HR table — and nobody at the ERP end is told. OneLake security and workspace roles become the control plane, so the access model has to be rebuilt there deliberately.
This is the one to design before you connect anything.
One workspace setting cannot be changed later
A Synapse workspace needs a managed virtual network to hold managed private endpoints, and Microsoft states plainly that the workspace configuration cannot be changed after creation. Get it wrong and the documented fix is a new workspace and a re-pointed Synapse Link profile — not a setting.
A five-minute decision at creation, or a migration later.
Unlinking deletes the lakehouse
Removing the Fabric link does not detach and leave the data behind. It deletes the Fabric lakehouse. Anything built on top of it goes with it.
Do not build on the lakehouse name
Microsoft says explicitly not to take a dependency on the generated lakehouse name, which carries environment, profile and workspace segments and is not stable. Reference workspace and lakehouse by ID. A large share of the pipeline examples in circulation parse the display name.
You cannot sync only what you need
Every non-system Dataverse table with change tracking on is selected automatically and cannot be removed, because Dynamics and partner apps depend on them. F&O tables you can choose. So the scope is half yours and half decided for you, and the storage follows.
The storage bill lands somewhere unexpected
Fabric link storage is charged against Dataverse database capacity, not against Azure. It surfaces in the Power Platform admin center as extra files, which is not where anyone looks first when a capacity alert arrives.
The lake is read-only
There is no write-back from the lake to Finance & Supply Chain Management. A number computed in Fabric reaches the ERP only through an integration path, which is a separate design with its own guarantees.
One retirement date is genuinely contested
Microsoft's own transition FAQ and Microsoft's tenant notifications disagree about when the Synapse trusted-services firewall exception retires. We will not state either date as settled, and neither should a plan. Check Service Health for your tenant, and do the remediation, which does not depend on the date.
The modelling, the pipelines, the governance, the lineage
Four workstreams. Fabric supplies the platform; none of these arrives with it.
01
The modelling
Turning F&O and Business Central tables into something a person can ask a question of: business entities, conformed dimensions, the grain each measure is actually valid at, and the definitions written down so two teams stop reporting two different revenue numbers.
02
The pipelines
The path from ERP to lakehouse and everything it has to survive: schema drift, late-arriving changes, reprocessing without double counting, and a failure at hour nine that resumes rather than restarts.
03
The governance
The access model rebuilt where the data now lives, because the ERP one did not come with it. Which roles see which legal entities, which columns are restricted, and how that is enforced in OneLake and Power BI rather than assumed.
04
The lineage
A traceable line from a figure on a dashboard, or in a Copilot answer, back to the ERP record behind it. This is what makes an AI answer auditable, and it is the difference between a system people use and one they quietly check by hand.
This is the oldest thing we do, not the newest
Cognilium AI started in large-scale data engineering, and an AI-ready ERP data estate is exactly that discipline pointed at a new platform. Pipelines that resume, schemas that are validated before anything is indexed, joins that hold at volume, and a governance model that was designed rather than inherited. Fabric changes where the work runs. It does not change what makes it correct.
An optimization app is only ever as good as the data layer it computes on, which is why we would rather build that layer than assume it.
Fabric and Dynamics 365, answered plainly
- What is Microsoft Fabric for Dynamics 365?
- Fabric is the analytics platform Dynamics 365 data lands in so that things other than Dynamics can use it. For Finance & Supply Chain Management and Business Central, Link to Microsoft Fabric shortcuts a managed copy of your data into a OneLake lakehouse, which Fabric provisions alongside a SQL analytics endpoint and a Power BI semantic model. Reporting, Copilot and AI agents then read from one governed source instead of several extracts.
- Should I use Link to Fabric or Azure Synapse Link?
- Use Link to Microsoft Fabric if you already run Fabric or will soon: there is no copy, no ETL and no storage account to manage. Use Azure Synapse Link for Dataverse if you need the data in your own storage account or in non-Microsoft tools, or if you need an incremental change feed into a downstream warehouse. Both are generally available; the choice is about who owns the storage.
- What is the difference between OData and Microsoft Fabric for Dynamics 365?
- They do different jobs. OData is a courier: send it for one record and it fetches or writes that record immediately, which makes it the only one of the two that can put data back into the ERP. It runs on the ERP's own capacity and has a practical ceiling in the order of a thousand to a few thousand records an hour. Link to Microsoft Fabric is a continuously maintained mirror you can run heavy analysis against without the ERP feeling it, but it is read-only. Most estates need both.
- What does "AI-ready data" actually mean for an ERP?
- Four things, and the phrase is worth nothing without them. Connected: one governed copy rather than several drifting extracts. Modelled: business meaning rather than raw table names. Governed: row-level access decided once and enforced where the data lives. Traceable: lineage from a dashboard figure back to the ERP record, so an AI answer can be audited.
- Does row-level security carry from Dynamics 365 into Fabric?
- No, and this is the most expensive assumption in the whole area. Extensible data security policies are bypassed for the Synapse Link service, so anyone with lakehouse access can see every legal entity, every cost price and every restricted HR field. Access has to be rebuilt in OneLake security, workspace roles or Power BI before the data is exposed to anyone.
- Can Fabric write back to Dynamics 365?
- No. The lake is read-only. A figure computed in Fabric reaches Finance & Supply Chain Management only through an integration path — an API, a data entity, dual-write or a queued pattern — each with its own throughput limits and ordering guarantees. Treat the write path as a separate design, because it is one.
- Is BYOD retired?
- Not formally. Microsoft groups it with the legacy paths and recommends transitioning to Synapse Link or Fabric link, but it has stated that a retirement date has not been determined. "Recommended against" and "retired" are different things, and plans built on the second one when the first is true tend to move faster than they need to.
- Do I need Fabric before I can use Copilot or AI agents on ERP data?
- Not strictly, but the failure mode without it is consistent. Copilot and agents answer from whatever they can reach, and if that is several extracts with different refresh times and no shared definitions, the answers will disagree with each other and with the ERP. A governed foundation is what makes the answers reconcilable.
- What does a Fabric data foundation project involve?
- Four workstreams: the modelling that turns ERP tables into business entities with defined grain, the pipelines that survive schema drift and reprocessing, the governance that rebuilds the access model where the data now lives, and the lineage that makes any number traceable to its source record. We would rather build that layer than assume it.
32 articles on the Dynamics 365 data estate
Each one answers a single question, sourced to Microsoft’s own documentation, with the date it was verified. Start wherever the project already is.
Getting the data out
The paths, the one that is contested, and the one that is not dead
- Fabric link or Synapse Link: which analytics path for Dynamics 365 data?
- Did the Synapse trusted-services firewall exception retire on 1 August 2026?
- Is BYOD retired?
- Why are virtual tables fast in the demo and slow in production?
- Does row-level security carry from Dynamics 365 into Fabric?
- Where does the storage bill land for Link to Microsoft Fabric?
- What happens when you unlink Dynamics 365 from Microsoft Fabric?
Decisions that set the platform
Cheap to make now, expensive to discover later
- Is "Dynamics 365" one product?
- Business Central or Finance & Operations: which Dynamics 365 ERP, and what does the choice decide?
- Which Dynamics 365 environment tiers do you actually need?
- Which Dynamics 365 regions can you actually deploy into?
- The 2026 capacity model: what changed, and what happens on overage?
- What does a Dynamics 365 quote actually cost: base, attach and the minimums?
- AL or X++: what building on each ERP actually commits you to
- Seven Azure reference architectures for AI on Dynamics 365, and the eighth we refused to draw
Staying current
What the release cadence commits you to after go-live
- What does One Version actually guarantee, and what does it not?
- What does "keeping current" mean when there are three release trains?
- Business Central or F&O: the update cadence, and what each costs in change management
- What is on the Dynamics 365 deprecation calendar, and what breaks on each date?
- LCS is going away: what breaks when you move to the Power Platform admin center?
- Why does the go-live assessment gate projects nobody scheduled for?
Putting data back in
The lake is read-only, so the write path is its own design
- How does a third-party app read and write Dynamics data without touching the ERP core?
- Microsoft names six Dynamics 365 integration patterns. Which for which job?
- Your optimizer is only as good as its write path. How should it read and write Dynamics 365?
- Which Dynamics 365 service protection limits are actually enforced?
- Why does your OData integration slow down at a few thousand records an hour?
- How do you move a million rows into Dynamics 365 without breaking it?
- What does dual-write actually cost you in transaction budget?
- Business events give you no ordering guarantee. What do you build instead?
- Why do your data events never fire for some entities?
- Why do recurring integrations create duplicate documents?
- What can't Dynamics 365 do natively for EDI?