Microsoft Fabric for Dynamics 365

Microsoft Fabric is a unified, software-as-a-service (SaaS) data analytics platform that consolidates data storage, data engineering, data integration, data warehousing, real-time analytics, data science, and business intelligence into a single product with one commercial and governance model. For the Dynamics 365 (D365) professional, Fabric is significant because it removes the friction between operational data locked inside D365 and the analytical work — reporting, forecasting, cross-system analysis — that business users perform every day.

This paper is written for a reader who is fluent in Excel (maybe some Power BI) and the day-to-day of Dynamics 365 Business Central (BC), Dynamics 365 Finance & Operations (F&O), or Customer Engagement (CE), but who is not a data engineer. Every concept is grounded in tasks a D365 power user already performs, then extended with the architectural detail needed to evaluate, scope, and defend a first Fabric project.

Repeated manual exports. Analysts export the same D365 entities to Excel every week or month, re-applying the same transformations by hand.

Fragile spreadsheets. Reports break when a workbook is renamed, a column is moved, or a formula is overwritten.

Scattered copies. The “same” data lives in dozens of Excel spreadsheets, network drives, and personal Power BI files, each subtly different and none authoritative.

No history. D365 retains current state; it is not designed (without extensions or customizations) to preserve the daily or monthly snapshots needed for trend analysis.

Siloed systems. Combining BC / F&O financials with CE opportunities, or with an external budget file, means manual joins that are error-prone and unrepeatable.

• No silos. Every Fabric workload reads and writes the same OneLake. There is exactly one copy of a given table, and every engine sees it.
• Automatic, not provisioned. Unlike a traditional data lake (which requires creating and configuring a storage account), OneLake exists the moment your tenant is enabled.
• Organized by workspace. OneLake is structured into workspaces and then into items (lakehouses, warehouses). This maps cleanly onto the Power BI workspace model users already understand.

3.2 Shortcuts: Reference Data Without Copying It

A defining OneLake feature is the shortcut — a pointer to data that lives elsewhere (in another workspace, in Azure Data Lake Storage, or in Amazon S3) that makes it appear as if it were local, without physically copying it. For D365 scenarios, shortcuts let you surface data already landed by other tools into your own lakehouse, avoiding duplication and keeping a single source of truth.

3.3 Open Storage Format

OneLake stores tabular data as Delta Lake tables backed by Parquet files. Delta adds transactional reliability (ACID), versioning (“time travel”), and schema enforcement on top of the open Parquet columnar format. The practical consequences for a business user: data is compressed and fast to query, it is portable and not locked in, and it can be read by many engines at once.

Same familiar editor.
The Power Query Online experience — connectors, applied steps, the M language — is identical to what you know.

Reusable and shared.
Instead of each analyst re-cleaning the same export, one dataflow defines the transformation once; everyone consumes the result.

Scheduled refresh.
Dataflows run automatically, so the curated table is always current without manual intervention.

Hundreds of connectors. Including native connectors for Dynamics 365, Dataverse, SQL, SharePoint, web APIs, and files.

Import

Data is copied into the model’s memory. Fast queries, but data is a snapshot that must be refreshed, and large models consume memory.

DirectQuery

Queries pass through to the source at run time. Always current, but performance depends on the source.

Direct Lake

A Fabric-only mode that reads Delta-Parquet files directly from OneLake with near-import performance and near-DirectQuery freshness — without importing or duplicating the data.
This is one of Fabric’s most important innovations for BI at scale.

This deserves its own warning because it defeats the otherwise excellent shortcut pattern. BC column names carry special characters — $Company, and system fields rendered as names like systemId-2000000000. Parquet files written with those names are not recognized by Fabric Lakehouse shortcuts, which is why teams historically kept a translation or staging layer between the data lake and Fabric. Open Mirroring sidesteps the problem by handling the schema through a metadata definition rather than shortcut inference. If you intend to use plain shortcuts over raw BC exports, plan for a renaming step.

• Link to Microsoft Fabric handles incremental synchronization for you: Dataverse keeps the OneLake copy continuously up to date, including inserts, updates, and deletes, with no pipeline to author.
• Dataflows Gen2 support incremental refresh by defining a date/watermark column and a refresh window, so only recent partitions are reprocessed.
• Pipelines can implement high-watermark patterns using a control table that records the last-loaded timestamp per entity.

• Business Central gives you two purpose-built watermark columns on every table: SystemModifiedAt and SystemRowVersion. Track whichever your tooling prefers — a date or a rowversion — and read changes since that mark. This is also what makes BC pipelines safely rerunnable after a timeout, which matters given the throughput ceiling in Section 8.11.
• A deprecation note for BC teams. Delta links were deprecated in Business Central 2023 release wave 2 and 2024 release wave 1; webhooks are the recommended replacement for change notification. Do not design new BC ingestion around delta links.

How fresh is the data?

Link to Microsoft Fabric offers near-real-time synchronization; scheduled dataflows and pipelines are as fresh as their schedule (commonly hourly or daily). For Business Central, Open Mirroring is the freshest practical option — production implementations report latency in the range of ten to fifteen minutes, replacing batch patterns that managed only a handful of refreshes per day. Match the latency to the business need: a monthly financial report does not require minute-level freshness.

Does analytics load the ERP?

A key advantage of landing data in OneLake is that downstream analytics query the lake, not the live D365 database. This isolates heavy reporting workloads from the operational system, protecting transaction performance — a concern with older “report directly against the ERP” approaches.

Per-call Throughput

Measurements show it is not unusual to read approximately 2 MB per second per API call — roughly 120 MB per minute, or about 7,200 MB per hour for pipelines running sequentially.

Parallelism

Business Central online currently permits five parallel API calls. That puts the practical upper bound near 35 GB per hour, and only if nothing else is calling web services on the environment.

Initial Load Duration

At that rate, a 100 GB database can take up to a full day to read. This is a one-time cost, and it is precisely why the BACPAC route exists for history.

Nightly Delta Feasibility

For an ETL setup that refreshes a staging area overnight with the prior day’s changes, this throughput fits most maintenance windows — unless the environment genuinely produces several gigabytes of new or changed data per day.

9.1 What it Can Replace

• Manual, repeated exports of D365 data into Excel workbooks.
• Scattered, divergent copies of the same data across spreadsheets.
• One-off Power BI datasets that each analyst rebuilds independently.
• Fragile links between spreadsheets, network drives, and reports.
• Ad hoc, unrepeatable cross-system joins.

9.2 What It does not replace

Dynamics 365 remains your system of record. Fabric reports on operational data; it does not run operations. You still create orders, post transactions, and manage customers in D365. Fabric is the analytical mirror, not a replacement for the ERP/CRM. This distinction is essential when setting expectations with stakeholders and executives.

Consolidated cross-application reporting

Combine F&O financial data and CE sales data in a single Power BI model, eliminating manual reconciliation between systems

Blending D365 with external sources

Join Dynamics 365 data with budgets, third-party CRM extracts, web data, or spreadsheets to produce analysis no single system can

Automated, refreshed datasets

Replace the nightly or weekly Excel export with a lakehouse table that refreshes on a schedule and feeds reports via Direct Lake.

A governed single source of truth

Publish one certified semantic model so every analyst and executive reports on the same numbers and definitions. No Excel data silos!

Multi-company and multi-environment consolidation

A common BC reality is several companies in one environment, or several environments across acquired entities. Landing all of them in one lakehouse with company as a dimension produces a group-level view that BC’s per-company reporting cannot deliver.

Mixed-estate reporting across Dynamics products

Organizations that run BC in subsidiaries and F&O at corporate — a frequent pattern after acquisitions — can report across both once each is landed in OneLake and keys are conformed.

Historical trend and snapshot analysis

Persist daily or period snapshots of D365 data that the operational system itself does not retain (again, without customization), enabling true trend analysis.

Self-service with guardrails

Give analysts access to trusted, classified data while enforcing row-level security so each sees only what they should.

• Environment separation. Keep development, test, and production workspaces separate and promote content through Fabric deployment pipelines.

• Cataloging and lineage. Microsoft Purview integrates with Fabric to catalog assets and trace lineage from the D365 source through to the Power BI report.

• Start small. A low F SKU is enough for a pilot; capacity can be scaled up or down and paused to control cost.
• Capacity is shared compute. All workloads (dataflows, warehouse queries, report rendering) draw from the same capacity, so size for peak concurrent demand.
• Pausing saves money. Pay-as-you-go F capacity can be paused when not in use — useful for dev/test.

• Account for the ingestion mechanism’s cost. The Dataverse (F&O / CE) link consumes little Fabric compute because it creates shortcuts rather than copies. BC pipelines and dataflows do consume CU on every run, so a fifteen-minute refresh cadence is a capacity decision, not just a latency one. Open Mirroring shifts CDC processing to the platform and generally costs less than an equivalent pipeline-and-Spark chain.

The single most important recommendation for a first project: start small and deliver one measurable win. Avoid a big-bang platform migration.

13.1 Scope

Pick one painful report — ideally one that is currently rebuilt from manual D365 exports. Connect that data, model it once, and publish it. A tightly scoped pilot proves value quickly and builds organizational confidence.

1

Create a workspace and assign it to the capacity

2

Bring the data in*

3

Land the data in a lakehouse; verify tables and refresh

4

Build a semantic model over the lakehouse using Direct Lake

5

Author the report in Power BI; apply RLS if needed

6

Share with the pilot audience via a security group; measure the win

Over-scoping
Trying to model the entire ERP at once instead of one report.

Skipping Governance
Sharing broadly before applying RLS or organizing workspaces.

Under-sizing or Over-sizing Capacity
Start small, monitor the capacity metrics app, and adjust.

Treating Fabric as a Replacement for D365
It is the analytical layer, not the operational system.

Assuming the Dataverse Link Works
The most common planning error in mixed estates. Budget real effort for BC ingestion.

Ignoring the BC API Throughput Ceiling
Committing to a large initial load through APIs alone, without the BACPAC route, turns a one-week pilot into a one-month one.

A minimal, defensible first architecture reads left to right:

• Source:
  • Dynamics 365 (F&O and/or CE) → Dataverse.
• Ingestion:
  • Link to Microsoft Fabric (no-copy) or Dataflow Gen2 (with transformation).
  • Open Mirroring via bc2adls (lowest latency), or Dataflow Gen2 / pipelines over API pages with a SystemModifiedAt watermark; BACPAC restore for the one-time historical load.

• Storage: OneLake, organized as a Lakehouse holding Delta tables.
• Modeling: A semantic model in Direct Lake mode over the lakehouse.
• Consumption: Power BI reports and dashboards, secured with RLS and shared via groups.
• Governance (cross-cutting): Microsoft Purview for catalog, lineage, and classification.

This pattern scales: additional sources become new lakehouse tables or shortcuts; additional audiences become new reports over the same governed data model.

• Fact tables hold the measurable events — sales order lines, invoice transactions, inventory movements — at a defined grain, with numeric measures and foreign keys.
• Dimension tables hold the descriptive context — customer, product, date, legal entity, salesperson — that you slice and filter by.

D365 operational schemas are highly normalized (many related tables) because that is efficient for transactions. Analytical modeling denormalizes them into a smaller number of wide dimensions and clean facts, which the Power BI engine handles far more efficiently than dozens of normalized joins.

Build a proper date dimension. Do not rely on raw transaction dates; create a dedicated calendar table to support period-over-period analysis, fiscal calendars, and time intelligence.

Conform keys across products. When combining systems, map customer and product identifiers to a single conformed key so the same entity aligns across facts. With three possible sources this becomes a discipline rather than a step — see Section 16.3.

Handle currency and the entity dimension early. Multi-entity D365 deployments carry multiple currencies and organizational units; normalize these in the silver layer so reports do not sum incompatible values. Note the vocabulary differs: F&O uses legal entity, while Business Central uses company, exposed in exports as $Company. Model one conformed organizational dimension and map both into it.

Model slowly changing dimensions where history matters. If a customer’s segment or a product’s category changes over time and you need historical accuracy, implement a slowly changing dimension rather than overwriting the attribute.

Keep measures in the semantic model. Define business calculations (margin, days sales outstanding, backlog) as DAX measures in one certified model, not re-derived in each report.

A workable approach:

• Build an explicit crosswalk table. Hold one row per real-world entity with its identifier in each source system. Maintain it as data — sourced from a master-data process where one exists — not as DAX or hard-coded logic.
• Create a surrogate key in the silver layer. Assign your own conformed key and carry the source system name plus the native identifier as attributes. Never reuse one system’s key as the conformed key; the first acquisition will break it.
• Define a surviving-record rule. When the same customer exists in BC and F&O with different names, addresses, or terms, decide in advance which source wins per attribute, and record that decision in the catalog / transformation logic.

• Keep the organizational grain unambiguous. Every fact row should carry both the conformed organizational key and its native company or legal entity value, so a discrepancy can always be traced back to the source.
• Do not attempt three-way conforming in the pilot. Land one product, prove the model, then add the second. Conforming is where cross-product projects overrun, and it is entirely avoidable in phase one.

• Shared, smoothed compute. Every operation — a dataflow refresh, a warehouse query, a report render — consumes CU from the same capacity. Fabric smooths consumption over time, spreading short bursts so that occasional spikes do not immediately fail.
• Throttling and bursting. If sustained demand exceeds the purchased capacity, Fabric first allows short bursting, then throttles interactive and background operations. Persistent throttling is the signal to optimize workloads or scale the SKU up.
• The Capacity Metrics app. Microsoft provides a monitoring app that shows CU consumption by item and operation. Install it early; it is the primary tool for right-sizing and for identifying expensive dataflows or queries.

• Prefer incremental over full loads to cut ingestion cost dramatically.
• Let V-Order and table maintenance do their job. Fabric writes optimized, compressed Delta files (V-Order); periodic table maintenance (compaction) keeps queries fast on tables with many small files.
• Right-size semantic models. Remove unused columns and high-cardinality fields the report does not need; they inflate model memory and can trigger Direct Lake fallback.

• Schedule heavy jobs off-peak so background refreshes do not compete with interactive reporting during business hours.
• Pause non-production capacity. Pay-as-you-go dev/test capacity can be paused outside working hours to avoid charges.

Deployment Pipelines

Fabric deployment pipelines promote content from development to test to production workspaces with deployment rules that repoint data sources per environment, so production never reads from development data.

Git Integration

Workspaces can connect to Azure DevOps or GitHub, storing item definitions in source control. This gives you version history, code review, and the ability to roll back.

Environment Separation

Maintain distinct dev, test, and production workspaces with least-privilege access, and gate promotion with approvals.

Monitoring and Alerting

Beyond the Capacity Metrics app, use refresh-history monitoring and Data Activator to alert owners when a refresh fails or data quality checks breach a threshold.

Documentation and Certification

Endorse trusted semantic models as “certified” so consumers can distinguish authoritative datasets from experiments.

• Existing Synapse or Databricks lakes. Because OneLake speaks open Delta-Parque formats and supports shortcuts to ADLS and S3, existing lakes can be referenced in place, avoiding a forced migration.

• Existing Power BI Premium. Premium capacities include Fabric workloads, so many organizations can enable Fabric on capacity they already own before purchasing new F SKUs.

• Phased adoption. A defensible sequence is: (1) surface existing data via shortcuts, (2) build one gold-layer model and report, (3) migrate ingestion to Link/dataflows, (4) consolidate governance in Purview, (5) retire redundant legacy pipelines once the modernized data platform is proven.