Most Dynamics 365 Finance and Operations reporting problems are not reporting problems. They are access problems. The ledger, the subledgers and the operational detail all sit inside an application that was never designed to be queried directly, and the route you choose to move that data into Microsoft Fabric decides how much of the remaining work you will end up doing by hand.
Microsoft has changed that route more than once, so it is worth being precise about what is supported now, what has been retired and what each option means for latency, cost and modelling effort.
What has already gone
Export to Data Lake and Bring Your Own Database are legacy services. Support for Export to Data Lake in finance and operations apps ended on 1 November 2024. Both wrote CSV, both came with table restrictions, and neither supported firewall-restricted storage accounts, which is why so many estates ended up with a staging database and a Data Factory pipeline bolted on to make the output usable.
If either is still running somewhere in your environment, replacing it is a migration rather than a configuration change. The table shapes, the column names and the delete behaviour all differ from what your downstream models expect. Microsoft sets out the upgrade paths in its transition guidance for finance and operations apps.
The two supported routes out of Dynamics 365 Finance and Operations
Both current options run through Dataverse. Finance and operations tables are surfaced by the Dataverse link rather than read from the F&O database directly, so the Dataverse environment sits in the path whether or not your organisation thinks of itself as a Dataverse user.
1. Link to Microsoft Fabric
This is the managed option. Data stays inside the Dataverse governance boundary and appears in a Fabric lakehouse as OneLake shortcuts in Delta Parquet format. There is no pipeline to build, no storage account to size and no conversion job to monitor.
The prerequisites are specific. You need Fabric capacity or a Power BI Premium capacity in the same Azure region as the Dataverse environment, system administrator rights in the environment and admin rights on the Fabric workspace. Workspace identity is the cleanest authentication choice because it avoids managing a secret. Refresh is usually within the hour, commonly 15 to 45 minutes, though that is not guaranteed during heavy transaction periods such as master planning runs. Linked tables consume Dataverse storage quota, and the link will fail in environments with more than 2,000 active Dataverse tables.
If you need row-level change history, the change data feed keeps inserts, updates and deletes for roughly 24 hours. It has to be enabled deliberately in the Power Platform admin centre and it costs you some latency.
2. Azure Synapse Link for Dataverse
This option writes to a storage account you own. Data lands in Delta Parquet, you select up to 1,000 tables per profile and you set the conversion interval at 5, 15, 60 or 1440 minutes. Shorter intervals mean more frequent Spark jobs and a higher compute bill, and the interval controls how often conversion runs rather than guaranteeing how fresh the data is.
Choose it when storage ownership actually matters: firewall-restricted storage, a retention policy that goes beyond what the managed link keeps, or existing Azure pipelines that are staying in place. One practical constraint catches people out. Finance and operations tables cannot be added to an existing Synapse Link profile pointing at a storage account already in use, so this needs a new profile.
A third variation people meet in practice
The two options are not mutually exclusive. If you already run Azure Synapse Link and have enabled Delta Parquet conversion for Fabric, you can surface that existing profile in Fabric as well, which creates a lakehouse, a SQL endpoint and a semantic model over the data already sitting in your storage account. It is a useful middle path for organisations that have invested in Synapse Link and want Fabric consumption without rebuilding the export. The catch is that it does not work with CSV output profiles, and a Dataverse environment currently links to a single Fabric workspace.
Tables or entities
Whichever link you pick, F&O data can arrive in two shapes and the difference is not cosmetic.
Raw tables are the F&O database tables. Custom tables need change tracking enabled before they appear, kernel tables are handled automatically, and they are not visible in the Power Apps tables area. They give you the true grain, which is what a lakehouse wants.
Data entities arrive as Dataverse virtual tables with an mserp_ prefix and need change tracking enabled per entity. They are already shaped into business objects, which is convenient, but they are narrower in coverage and they carry F&O application logic with them.
For finance and operational reporting I normally start with tables and build the business shapes in Fabric, where the logic is visible and testable, rather than depending on entity definitions that can change with an application update.
What the data looks like when it lands
The replicated tables are not identical to what you see in F&O, and the differences show up in reconciliation rather than at build time.
- Deleted rows are retained and flagged with isDelete. If your model does not filter them, your balances will be wrong.
- RecId is converted to a GUID and surfaced as Id, while the original integer is renamed FnO_Id.
- Column names that collide with SQL reserved words gain a trailing underscore, so Level becomes Level_.
- Memo fields are truncated at 2,000 characters. Binary fields, array type fields and TimeZoneId are excluded.
- Derived tables do not bring their base table columns with them. The base table has to be selected separately.
- Metadata columns such as sysrowversion, SinkCreatedOn and SinkModifiedOn are added and are useful for incremental logic.
- A database restore removes F&O tables from the profile and they have to be re-added.
None of this is a defect. It is the contract. A model built without reading it produces duplicated rows, missing deletes and period-end differences that nobody can explain quickly.
The modelling work does not disappear
Getting the data into OneLake is the easy half. F&O tables are normalised for transaction processing, not for analysis, and several structures need deliberate handling before finance will trust the output.
- Company scope. Nearly every table carries DataAreaId, and consolidated reporting has to decide how legal entities combine, including intercompany treatment.
- Financial dimensions. They are not columns on the transaction. They sit in dimension attribute value sets referenced by the ledger dimension, so cost centre and project analysis needs resolving before it can be sliced.
- Effective dating. Validity ranges on master data mean a naive join returns more rows than expected.
- Enumerations. Status and type fields arrive as integers and need labels that match what users see in the application.
- Ledger and subledger. Sales, purchase and inventory detail has to tie back to the general ledger, and the rules for that are a business decision, not a technical one.
In practice that means a landing layer holding the replicated tables as they arrive, a conformed layer where companies, dimensions, dates and enumerations are resolved, and a curated layer built around the grain finance actually reports on. Whether the curated layer sits in a Lakehouse or a Warehouse depends on who consumes it and how, which I covered in Lakehouse vs Data Warehouse in Microsoft Fabric.
Comparing the two routes
| Decision | Link to Fabric | Azure Synapse Link |
|---|---|---|
| Where data sits | Managed by Dataverse, surfaced as OneLake shortcuts | Your own Azure storage account |
| Running effort | No pipelines or Spark jobs to manage | You manage profiles, storage and conversion |
| Freshness | Usually 15 to 45 minutes | Conversion at 5, 15, 60 or 1440 minute intervals |
| Scope limits | Fails above 2,000 active Dataverse tables | Up to 1,000 tables per profile |
| Main cost | Fabric capacity and Dataverse storage quota | Azure storage, Spark compute and your own tooling |
| Best fit | Fabric is the target platform and you want the shortest path | Storage ownership, firewall rules or existing pipelines matter |
Where the cost usually goes wrong
The most common way to overspend is to select everything. F&O environments contain thousands of tables, most of which no report will ever touch, and every one you replicate consumes storage and refresh capacity. A table selection driven by named reporting domains, with an owner for each, keeps the bill predictable and makes the first reconciliation far quicker.
The second is sizing capacity against the initial load rather than the steady state, or the other way round. The first sync of a large finance table can take considerably longer than the incremental refresh that follows, so plan the cutover window around the initial copy and size the capacity for the ongoing pattern.
Reconcile against F&O, not against the lake
A Fabric report that agrees with another Fabric report proves nothing. The acceptance evidence has to come from the application: trial balance by legal entity and period, subledger totals against the ledger, open receivables and payables ageing at a fixed date, and row counts after the initial sync with an explanation for any difference.
Run that pack on a schedule rather than once at go-live. Schema changes arrive with F&O updates, and a check that only ran during the project will not tell you when a column quietly changed shape.
What a sound F&O to Fabric design includes
- A documented reason for the chosen link rather than a default
- A table selection tied to reporting domains with a named business owner
- Landing, conformed and curated layers with the finance grain agreed up front
- Explicit handling for deletes, company scope, financial dimensions and effective dates
- A reconciliation pack run against F&O on a schedule
- A capacity and storage estimate that still holds after the first month
- A process for handling schema change when the application is updated
Start with the questions finance already asks
The link itself is a technical choice that takes an afternoon to configure. The value comes from deciding which questions the platform has to answer, at what grain, for which legal entities, and then proving the answers against the system of record. Teams that start there usually reach a trusted number faster than teams that start by replicating every table they can see.
See the full D365 F&O and Fabric reporting service, the wider Microsoft Fabric implementation approach and data platform migration options. To discuss an F&O reporting assessment, contact Business Intelligence Atlas.
Comments are closed