Out-of-box service analytics or your own Power BI

What it does

Customer Service ships historical and real-time analytics as managed Power BI content — Customer Service historical, Omnichannel historical, knowledge analytics and Omnichannel real-time. You can take them as they come, customise the underlying data models inside Microsoft's Fabric workspaces, or ignore them and build your own reporting off Dataverse. Three routes, and clients pick the wrong one about half the time.

Key facts

The out-of-box reports are Power BI content hosted by Microsoft. Turning them on provisions a managed Fabric workspace holding the Dynamics data model; provisioning can take up to 24 hours.
Customising means a second, customer-owned Fabric workspace holding your edited reports, which then embed back into the app using the MscrmControls.Analytics.ModernReportingControl control.
You can embed up to 40 customised reports back into Dynamics 365. That is a real ceiling and it is generous for most clients.
You can edit the shipped data models, add metrics, and bring in custom Dataverse tables or entirely external sources into the customised model.
Automatic page refresh applies to real-time reports only, at fixed intervals of 5 or 10 seconds. Historical reports refresh on their own schedule; do not promise near-real-time from them.
Setup requires a Microsoft Entra ID security group containing the Dynamics 365 Analytics service account, and six specific Power BI tenant settings enabled in the Fabric admin portal, including "Embed content in apps".
Access follows Fabric semantic model permissions: authors need write on the semantic model, consumers need read, and embedded viewers need member access. This is a Fabric admin conversation, not a Dynamics one.
Report authors, developers, supervisors and administrators need appropriate Power BI or Fabric licensing on top of their Dynamics seat. The Dynamics licence alone does not cover building.

When to use / skip

Start with the out-of-box reports, unchanged, and run them for a quarter. This is the recommendation and it is the one most often skipped, because reporting requirements get gathered in workshops where nobody has yet seen what they already get. Half the "custom dashboard" list a client hands you in week two is already in the shipped Omnichannel historical report. Taking them as-is costs nothing but a tenant setting conversation and gives you a baseline that everyone can argue about with actual numbers.

Move to customising the shipped data models when the gap is specific and structural — the client's own case categorisation table needs to appear on every report, or a bespoke resolution measure needs to exist everywhere. Customising is the right call because you inherit Microsoft's model, their measures and their refresh, and you only maintain the delta. The 40-report embed ceiling is not what constrains you; the Fabric administration burden is.

Go fully independent — Dataverse to Fabric link or Synapse Link, own semantic model, own reports — when service reporting has to sit inside an enterprise reporting estate with a common date dimension, common customer master, and finance numbers alongside. Also when the client's BI team already exists, has standards, and will not accept Microsoft's model shape. In that situation the shipped reports become a supervisor tool for live queue health and nothing more, which is fine; real-time queue monitoring is genuinely hard to rebuild and worth keeping.

Skip the customisation route entirely for small clients. If there is no Fabric capacity, no BI team and no Power BI Pro budget beyond a handful of seats, you will build something nobody can maintain. Take the out-of-box reports, add two or three Power BI reports built directly on Dataverse for the specific gaps, and stop.

Configuration decisions

Which of the four report families to enable at all. Every one you enable is a data model to provision and a set of permissions to manage; enabling all of them by reflex creates admin work with no consumer.
Whether real-time Omnichannel analytics is needed, and if so whether the 5 or 10 second refresh drives a wallboard, a supervisor screen, or both.
Whether reporting is customised inside Microsoft's model or rebuilt independently on a Fabric or Synapse link from Dataverse. Pick one; running both is how you get two versions of the same number.
Who holds the Fabric workspace roles and how that maps to the client's existing BI governance. Handing the CRM team a Fabric workspace with nobody else's oversight tends not to survive contact with the BI function.
Which custom Dataverse tables are brought into the customised model, and whether the measures on them are defined once centrally or per report.

Gotchas

The tenant settings are the blocker on nearly every project. Six Power BI settings and an Entra security group usually sit with a team that is not on the project, and the lead time is measured in weeks. Raise it in week one.
Provisioning up to 24 hours means you cannot enable analytics on the morning of a demo. Plan it a working week ahead.
Customising the shipped model puts you on Microsoft's upgrade path for that model. When they change it, your delta may need rework. Keep the delta small and documented.
Power BI licensing for authors gets forgotten in the Dynamics business case, then blocks the build. Confirm who has what before you promise a custom report.
Two reporting routes running in parallel — shipped reports plus an independent Fabric model — produce different case counts because of different filters on cancelled and merged cases. Agree the definitions once and write them down.

Consultant notes

Show the client the shipped reports in a demo tenant before the reporting workshop. It removes about half the requirements list and the half it removes is the half that was already built.
Get the definition of "resolved case" agreed and signed in design. Every disagreement about service reporting is ultimately a disagreement about that one definition.
Before go-live, check that at least one named supervisor can open the real-time report on their own account with their own permissions. Embedded reporting fails on access far more often than on content.
If the client has a BI team, bring them in at design rather than presenting them with a finished Fabric workspace. That relationship determines whether the reporting survives the first year.

Worth another look when the shipped data models change shape, or if the embed limit or refresh intervals move in a future release wave.