Power BI vs native Dynamics 365 reporting

What it does

Two reporting surfaces over the same Dataverse data. Model-driven apps ship views, charts and dashboards that read live from Dataverse inside the app. Power BI builds a semantic model over that data — usually alongside other sources — and serves reports through the service or embedded back into the app.

Key facts

Native model-driven charts and dashboards read Dataverse live. There's no refresh, no model, and no lag between a record changing and the chart moving.
Native dashboards are scoped to the app and inherit Dataverse security automatically. Row-level security is the record-level security you already configured — no second model to maintain.
Power BI content can be embedded back into model-driven apps in more than one way: as a Power BI embedded system dashboard, as a Power BI report inside a system form, as a visualisation on a personal dashboard, and by visualising a view directly in Power BI.
Embedded Power BI in a form can be filtered by record context, or left unfiltered. Contextual filtering is a design decision, not automatic.
Power BI applies its own security model. Dataverse record-level permissions do not carry through into a Power BI semantic model — you rebuild that as RLS or accept a broader audience.
Native charts are limited in visual type, aggregation and formatting compared to Power BI, and can't join data from outside Dataverse.
Power BI over Dataverse can use the Dataverse connector, Dataverse link to Fabric, or a downstream warehouse. Each has different latency and modelling characteristics.
Power BI licensing applies independently of Dynamics licensing. A Dynamics user is not automatically licensed to view Power BI content outside qualifying capacity.

When to use / skip

Native wins for operational reporting inside the app. A salesperson looking at their pipeline, a service manager checking today's queue, a dashboard whose whole purpose is "click through to the record and do something" — that belongs in the app, live, with Dataverse security doing the work. Rebuilding that in Power BI means you've reimplemented record-level security, introduced refresh latency, and taken away the click-through that made it useful.

Power BI wins for analysis. Anything with history, trend, comparison across periods, or data from more than one system is a Power BI job and always will be. Native charts run out of road quickly — the moment someone asks for year-on-year with a target from a spreadsheet, you're building a semantic model.

The line to hold is that these aren't competitors and shouldn't be presented as a choice. A well-run Dynamics deployment has both: native views and dashboards for the operational layer, Power BI for the analytical layer, and Power BI embedded into the app where the analysis needs to sit next to the work.

Configuration decisions

Operational or analytical for each requirement. Ask "does the reader act on a record, or make a decision about the business?" — that separates the two cleanly.
How Power BI gets the Dataverse data: connector, link to Fabric, or a warehouse. Latency, volume and whether other sources are joined all point at different answers.
Whether Power BI content is embedded in the app or consumed in the service. Embedding keeps users in one place; it also means the Power BI licensing applies to app users.
Whether embedded reports filter by record context, and what happens when they don't match.
How security is reproduced in Power BI. Dataverse hierarchies and teams don't translate, and the effort to replicate them is often underestimated by a factor of three.
Who owns the Power BI content — the Dynamics implementation team, or the BI team. Both is the answer nobody plans for and everybody gets.

Gotchas

Dataverse security not carrying into Power BI is the big one. A report built by a system administrator shows everything, and nobody notices until it's shared with the sales team and they can see each other's numbers.
The Dataverse connector against a large table is slow, and clients try to fix a modelling problem with a connector choice. Volume above a few million rows wants Fabric or a warehouse, not a better connector.
Licensing surprises. Dynamics licences don't grant Power BI viewing rights in the general case, and embedding a report into a form doesn't change that.
Native charts get pushed past their limit and end up as twenty near-identical dashboards nobody maintains. That's the signal to move to Power BI, and it's usually spotted a year late.
Embedded reports in forms without contextual filtering confuse users badly — they expect the report to be about the record they're looking at.
Option set and choice columns come across as values that need mapping. Getting readable labels into the model is more work than people budget for.

Consultant notes

Set the boundary in the design phase and write it into the solution architecture. "Operational in the app, analytical in Power BI" is a sentence the client will remember and use.
Raise the security reproduction cost early and loudly. It's the item most likely to blow the estimate on a Dynamics-plus-Power BI engagement.
When the client asks for "the same dashboard but in Power BI", ask what they'll do with it. Half the time the requirement is a native chart they haven't found yet.
Where Dynamics data volume is real, get the Fabric or warehouse conversation started before anyone builds against the connector. Migrating a model off it later is a rebuild.
Check who is licensed for what before demoing embedded Power BI to a room full of Dynamics users. It's an awkward question to answer afterwards.

Recheck the embedding options in model-driven apps — the surfaces available have grown steadily and this list dates quickly