Power BI for Dynamics 365

Power BI is the default analytics layer for any Dynamics 365 customer. Microsoft ships pre-built Power BI apps for every major Dynamics 365 product, and customers extend or replace them with their own. The biggest design choice is where the data sits — and there are now three serious answers.

Pre-built Power BI apps

From the Power BI app marketplace, install Microsoft's published apps for Sales, Customer Service, Finance, Business Central, Supply Chain, Field Service, and Project Operations. Each app contains a curated dataset, dashboards, and reports tuned to the source product. Out of the box, these answer 80% of the typical analytical questions and are the right starting point even if you eventually replace them. For pixel-perfect, print-ready output — a statutory form or an invoice-style report rather than an interactive dashboard — paginated reports is the right tool alongside these apps, not a replacement for them.

Direct connectors

Power BI has first-class connectors to:

• Dataverse — direct query against the Dataverse SQL endpoint or import via the Dataverse connector. The right pattern for CRM-side reporting where data volumes are modest and you want live numbers.
• Business Central — REST API and OData connectors. Fast for moderate volumes; for years of history, prefer the data lake export.
• F&O entity store / data lake — historical fact-table extracts for large reporting needs.

Microsoft Fabric and OneLake

The strategic direction. Synapse Link for Dataverse streams Dataverse changes into OneLake near-real-time; Synapse Link for F&O does the same for Finance/SCM. The result is a Fabric lakehouse containing both CRM and ERP data, queryable with Power BI's DirectLake mode for fast performance without import refreshes. For mid-to-large customers, this is becoming the default analytics architecture.

Embedding

Power BI reports embed inside Dynamics 365 model-driven apps as system charts or as embedded reports in dashboards. Embedded reports respect row-level security configured in Power BI.

Row-level security

Power BI supports row-level security (RLS) that scopes data per user — typically by mapping a Dataverse business unit or territory to an RLS role. Configure it in Power BI Desktop, deploy to the service, and reports show each user only their data.

Performance

Import models are fastest for end users but require scheduled refresh — and are the models that hit dataset refresh failures when a source schema or credential changes. DirectQuery is live but slower and load-sensitive. DirectLake bridges the two, querying OneLake parquet without import. Pick deliberately per dataset.

Costs

Power BI Pro per user, Premium per user, or Premium capacity. Pre-built apps require at least Pro for end users; large embedded scenarios usually justify a Premium capacity.

Operational reality

Don't build a custom Power BI model the day before go-live. Start with Microsoft's app, evolve from real user questions, and migrate to Fabric when scale demands it.

Choosing the storage layer: a decision matrix

Situation	Right architecture
A single BC company, less than 100 users, ad-hoc finance and inventory reports	BC's built-in analytical reports + Power BI direct connector against the API
A Sales-only CRM, under 500k rows across accounts + opportunities + activities	Dataverse DirectQuery with the pre-built app extended in place
Sales + Service + Field Service, multiple business units, mixed live and historical	Synapse Link for Dataverse into OneLake, Power BI DirectLake mode
F&O only, single legal entity, standard modules	The published F&O Power BI apps + Data Lake export for history
F&O + Business Central + Dataverse, multi-country, cross-domain KPIs	Fabric lakehouse via Synapse Link (both sides) with Power BI DirectLake
CRM data + external systems (Snowflake, Salesforce, SAP)	Fabric lakehouse with mirrored sources; Power BI on top of the unified model

The pattern repeated across every one of those is: land clean data once, model once, report many times. Custom Power BI models built directly on top of an OData endpoint tend to become impossible to maintain past 10-15 tables.

Common mistakes

• Rebuilding the pre-built app on day one. Microsoft's shipped app is usually 80% of what a finance or service team wants. Rewrite it once you know which 20% is wrong for you, not before.
• Forgetting to align RLS with Dataverse security. Reports show numbers no one on the CRM side can see, or vice versa, and trust in the numbers evaporates.
• Running DirectQuery on hundreds of millions of rows. The report page loads for 40 seconds, users stop opening it, and someone declares Power BI slow. Move to import or DirectLake; do not blame the tool.
• Ignoring workspace lineage. In a Premium workspace with pipelines you can promote dataset changes deterministically dev → test → prod. Without that, one broken measure ends up in production because someone published from Desktop straight to the wrong workspace.
• Underestimating capacity for embedded scenarios. A dashboard embedded in a public-facing portal at scale requires Premium capacity, not Pro. Model the peak-hour queries before committing to a design.

Governance in one paragraph

Power BI in a Dynamics 365 tenant needs the same treatment as any Power Platform product: tenant settings that restrict who can publish to production workspaces, sensitivity labels on the datasets that carry personal or financial data, workspace roles that map to real jobs, and an admin API job that exports the tenant's inventory of reports and datasets weekly so nothing is invisible to the platform team. The rest is normal report engineering.

Where to go next

The analytics layer underneath is Microsoft Fabric and Dynamics 365 and Synapse Link for Dataverse. On the Power BI side: row-level security, dataflows vs datamarts, and deployment pipelines for moving reports between workspaces.