Custom analytics data models in Microsoft Fabric

What it does

Microsoft provisions the out-of-box analytics semantic models into a Microsoft Fabric workspace you nominate, so your own report authors can extend them — add measures, bring in custom Dataverse tables or external sources, build composite models — and then embed the resulting reports back into Copilot Service workspace alongside the standard ones.

Key facts

Four steps: pick a Microsoft Fabric workspace, provision the data models, grant workspace permissions (Write for authors, Read for consumers), then optionally embed the finished reports back into the app.
Provisioning can take up to 24 hours. You can leave the settings page and come back, using Refresh to check.
Historical and real-time are provisioned separately. You may point both at the same Fabric workspace, but Microsoft creates a separate managed workspace for each.
You must enable at least one historical or real-time analytics report before you can start.
You need a Microsoft Entra ID security group containing the Dynamics 365 Analytics service principal as a member. Where that is not available, the Dynamics CCA Data Analytics service account is the documented alternative. Power BI grants permissions to groups, not to individual service principals, which is why the group is mandatory.
Six Fabric/Power BI tenant admin settings have to be on: Create workspace (new workspace experience); Service principals can call Fabric APIs; Service principals can create workspaces, connections, and deployment pipelines; Allow DirectQuery connections to Power BI semantic models; Allow XMLA endpoints and Analyze in Excel with on-premises datasets; and embed content in apps.
Maximum 40 reports can be added to the customised reports site map in Copilot Service workspace.
Real-time custom reports can use Power BI's automatic page refresh at 5 or 10 second intervals.
When Microsoft updates the underlying model, custom deployments do not pick it up automatically — you manually update the semantic model, refresh, then redeploy.
Reports are modified or deleted from the relevant customisation page (historical or real-time), and report users, authors, supervisors and administrators all need appropriate Power BI licensing. Microsoft points at the Product Terms rather than naming SKUs, so confirm the exact requirement with the client's licensing desk.

When to use / skip

Take this route when the client has a real, funded analytics requirement that the standard reports and the embedded editor cannot meet — custom entities in the reporting, measures with the client's own calculation, blended data from another system. It is the supported way to do that while keeping supervisors in one app rather than sending them off to a separate Power BI portal.

Skip it if the requirement is cosmetic, if the client has no Fabric footprint, or if nobody on their side owns Power BI. This is not a Dynamics configuration task: it needs a Fabric workspace, tenant-level admin settings, a security group, licences and someone who can write DAX and will still be there in a year. Half-built custom models are worse than none.

There is a middle path worth naming: build the reports in a plain Power BI workspace over Dataverse and leave the standard analytics untouched. You lose the embedded experience and the pre-built model, but you avoid the tenant settings, the service principal and the manual redeploy cycle. For clients whose reporting team already lives in Power BI, that is frequently the better answer.

Configuration decisions

Whether custom reporting goes down this route at all, versus a standalone Power BI workspace or accepting the out-of-box reports.
Which Fabric workspace to nominate, who owns it, and whether historical and real-time share it.
Who gets Write on the workspace. That list is your report author population and it needs governing, because they can change what the whole service desk sees.
Which security group carries the Dynamics 365 Analytics service principal, who maintains it, and whether the client's Power BI tenant admin will actually turn on the six required settings — some organisations refuse the service principal ones outright, which kills the approach.
Which reports get embedded into the workspace site map and in what order, keeping under the 40-report ceiling.
Who owns the manual redeploy when Microsoft updates the base model, and how that gets scheduled.

Gotchas

The tenant settings are the real blocker. They are Power BI tenant-wide, not environment-scoped, and a security team that has deliberately disabled service principal workspace creation is not going to reverse that for one Dynamics project. Test this assumption in week one, not week ten.
Up to 24 hours to provision means you cannot demo this on the day you decide to do it, and historical and real-time provision separately, so anyone assuming one setup covers both loses another day.
Microsoft's model updates do not flow through. Custom reports silently stay on the old model until someone does the manual update-refresh-redeploy dance, and "silently" is the operative word.
Workspace Write access is a broader permission than most clients realise. It is not the same as the Analytics Report Author role that governs the embedded editor, and conflating the two in a security design is common.
Licensing is not settled on this page. Do not quote Pro versus Premium per User versus Fabric capacity from memory — get it confirmed, because the difference between per-user licences for every supervisor and a shared capacity is a material cost.
Once supervisors are used to custom embedded reports, unwinding it is a project of its own. Treat the decision as effectively one-way.

Consultant notes

Raise the Fabric and tenant-settings prerequisites at the first analytics workshop, addressed to the client's Power BI admin, not their Dynamics admin. That approval chain is the long pole on every project I have seen.
Get the licensing position in writing from the client's licensing partner before you scope the work. It changes the business case more than the build effort does.
Insist on a named owner for the custom models on the client side. Without one, the manual redeploy never happens and the reports quietly rot.
Demo the embedded result, not the Fabric workspace. Sponsors care that supervisors stay in one app; they do not care about the plumbing.
If the prerequisites look unlikely to land, propose the standalone Power BI workspace early rather than letting the project drift into a stalled provisioning request.

Worth another look when the licensing requirements are stated more concretely, or if Microsoft automates the model-update redeploy.