Dynamics 365 reporting no longer needs a data pipeline you build and then spend years maintaining. Microsoft refreshed the Link to Fabric documentation on 29 September, and the picture it describes is unusually tidy: Link to Fabric now sits at the top of the new Link data page in Power Apps, marked as the recommended way to get Dataverse out for analytics, while Azure Synapse Link has moved to a secondary Other Links section. Behind it, a faster sync engine writes straight from the Dataverse database into Delta Parquet. For any team that has been nursing an extract job so finance can see pipeline next to revenue, that is a good week.
The gain runs deeper than quicker refreshes. Three changes landing together, table-level selection, keyless authentication and a row-level change history called Change Data Feed, move work out of a custom build and into configuration. The teams getting the most from it are the ones treating the table list as a deliberate design decision rather than a default to accept, because that single choice now sets both the cost and the clarity of everything downstream.
What did Microsoft change for Dynamics 365 reporting?
The consolidation is the visible part. Every route for moving Dataverse data out for analytics now starts on one Link data page, the Fabric option carries a Recommended badge, and you can no longer create an Azure Synapse Link from the Tables area at all. Connections support three authentication methods: an organisational account, a service principal built from tenant ID, client ID and key, or a workspace identity. Microsoft names workspace identity as the recommended option in plain terms, because it removes the need to manage secrets and avoids what the documentation calls the most common Fabric link setup failure, service principal misconfiguration. Table management has also become a standalone surface, so adding or removing tables no longer means editing the link itself.
The engine underneath is the substantive part. Low-latency sync, which Microsoft also calls Fast Fabric, writes directly from the Dataverse database to Delta Parquet and removes the intermediate CSV step the previous pipeline used. That takes a whole hop out of the chain and, with it, a set of failure points. Throughput for finance and operations tables now reaches up to a million or more records per hour per table, against a previous range of roughly 100,000 to 700,000. It has been generally available since July, it rolls out by station and enables itself with no opt-in, and you can confirm it by looking for the Low-latency mode flag on your Fabric link.
How do you integrate CRM with ERP data for reporting?
If your Dataverse environment is linked to a Dynamics 365 finance and operations environment, the table picker lets you select finance and operations tables alongside your Dataverse tables, and both arrive in the same Fabric lakehouse as OneLake shortcuts. A single query can then follow an opportunity through to the invoice it became, with no custom integration between CRM and ERP and no second warehouse to keep in step. Reporting reads the lakehouse while Dynamics 365 carries on serving the application. So the practical route to CRM and ERP reporting in one place is now configuration rather than development: choose the tables, point a semantic model at the SQL analytics endpoint, and let the sync keep them current.
For manufacturing and construction clients this is the join that has always been expensive to build and awkward to trust, because quote, order and delivery data sat one system away from the deal that created it. Two details are worth knowing before you start. Finance and operations tables are not selected automatically when you create the link, so you add them deliberately. And low-latency sync expects a supported build, with minimum platform and application versions published for releases 10.0.47, 10.0.48 and 10.0.49, which you can check under Help and Support then About. Applying the latest quality update for your version clears it.
Why does picking your tables beat syncing everything?
By default the wizard selects every Dataverse table with change tracking enabled, which in a mature organisation is a lot of tables. Only the tables you select consume storage in Fabric, and the Delta Parquet replica counts toward your Dataverse database capacity, so the picker is a cost control rather than a formality. Because table management is now its own surface, the list is easy to revisit as reporting needs settle. There is also a practical ceiling worth planning around: environments with more than 2,000 active Dataverse tables can fail to link at all, which makes a considered selection the faster path as well as the cheaper one.
CRM technical debt is the accumulated cost of the customisations, fields, integrations and workarounds that each made sense when they were added and now slow every change down. A table list is an unusually good place to see it. If nobody can say which of four hundred synced tables a report actually reads, that is debt made visible, and visible debt is cheap to act on. Clearing a table removes its OneLake shortcut and stops the sync without touching anything in Dataverse, so the whole exercise is reversible and low risk. Very few audits give you that much insight for that little commitment.
What does Change Data Feed give revenue operations?
Revenue operations is the function that owns the systems, data and process connecting marketing, sales and customer success, so pipeline can be measured and forecast end to end instead of department by department. Its hardest reporting questions are historical: which stage deals stall in, how the forecast looked three Tuesdays ago, how long qualification genuinely takes. Change Data Feed answers them from the platform. It is a Delta Lake capability that records row-level inserts, updates and deletes together with metadata identifying each change type, and low-latency sync preserves roughly 24 hours of it, which Microsoft points at time travel and funnel analytics.
This is exactly the work RevOps teams have been building by hand for a decade: a nightly job writing stage values into a history table so that someone can reconstruct a funnel later. Now it is a setting, under Settings, Product then Features in the Power Platform admin centre. One caveat, stated once: Change Data Feed is memory and compute intensive and can raise sync latency, so enable it on the environment where the funnel questions actually live, and land anything you need beyond 24 hours in a downstream table. That is a small piece of modelling in exchange for retiring a fragile snapshot job, and it is a trade most teams will take happily.
Why is CRM data quality important once reporting sits this close?
CRM data quality is important because every downstream number inherits it. When the analytics layer is a custom build, poor data tends to get quietly repaired in transit, and the cleaning logic becomes the real business definition without anyone deciding that it should. Link to Fabric shortens the distance: it replicates the tables you select into Delta Parquet, reports read that, and incremental updates typically appear within the hour. So a stage reps skip or an owner field left blank reaches the board pack the same morning. That immediacy is the advantage. It converts data quality from an invisible tax into something visible enough to fix.
Better still, the preparation it rewards is work worth doing anyway. Change tracking has to be on for a table to sync, which is a useful inventory of what the organisation actually considers a record of interest. Field discipline pays off twice, because schema rules here are clear and easy to design around: adding a column is supported and takes up to an hour to propagate, deleting one sends nulls forward rather than dropping it, and changing a column’s data type or precision is not supported, so that table needs removing and re-adding. Agree your types once and the sync simply keeps running.
What should you set up first, and how do you measure the return?
There is a short, concrete list for the week ahead. Check whether your link already carries the Low-latency mode flag. Confirm you have Fabric capacity in the same Azure geography as the Dataverse environment, which is a requirement and, for European organisations watching digital sovereignty, a helpful one, since the analytics replica stays in region. Move the connection to workspace identity. Then trim the table list. If you are relinking an existing profile to pick up the new engine, four differences deserve a look first: timestamps are written as INT64 rather than INT96, empty strings are preserved instead of becoming nulls, deletion vectors mean Synapse serverless SQL workloads should move to the Fabric SQL analytics endpoint, and long-term retained data is not surfaced through shortcuts until Microsoft completes its migration. Relinking triggers a full initial sync, so book it for a quiet weekend.
Measuring CRM ROI on a change like this works best when you baseline before you link. The honest measures are decision latency, how long it takes to answer a pipeline question, and trust, how many reports a leader reads without re-checking the number in the application. Both improve quickly here and both are easy to capture now. This is also where an independent CRM partner earns its place. An independent partner works across platforms and is paid for the outcome rather than the licence, so advice on what to sync, what to retire and whether the analytics layer belongs in Fabric at all comes without a vendor roadmap attached. On a decision that spans Dynamics 365, Dataverse, Fabric and whatever already runs your reporting, that neutrality is the practical value.
The Sirocco perspective
We work across Salesforce, HubSpot and Dynamics 365, and what strikes us about this release is how much of it is ordinary good practice finally becoming the default. Keyless authentication instead of a rotating secret. A deliberate table list instead of everything. Change history from the platform instead of a job somebody wrote and nobody owns. Our clients who get the most from Link to Fabric are the ones who spend a fortnight on the table selection and the field definitions before they build a single report, because that fortnight also improves routing, ownership and forecasting inside the CRM itself. If you have already read our note on how Microsoft automated CRM discovery, this is the same movement reaching the data layer: inventory first, then decisions, then build.
The direction here is encouraging. The reporting layer under Dynamics 365 is becoming something you configure and govern rather than something you engineer and defend, and that hands the advantage to organisations with clean definitions and clear ownership. If you would like a second opinion on which tables belong in your lakehouse, or on whether Fabric is the right home for your CRM reporting at all, we are happy to talk it through. Schedule a consultation and we will start with what you already have.
Get in Touch
If you are weighing up which Dynamics 365 tables belong in Fabric, or whether your CRM reporting should live there at all, we are glad to look at it with you.
