Customer Service historical analytics reports

What it does

A set of Microsoft-built Power BI reports, embedded in Copilot Service workspace, that report on case volumes, resolution performance and rep productivity from Dataverse case data. You switch them on with one toggle in the Copilot Service admin center and Microsoft provisions and refreshes the underlying semantic model for you.

Key facts

The toggle is Enable Customer Service historical analytics report, found in the Copilot Service admin center under Insights. It is off by default in a fresh environment.
The reports it lights up are Summary and Agent. Both are case-centric — this is the Customer Service side, not the conversation-centric omnichannel set.
Data refreshes every 24 hours. There is no custom refresh schedule and no on-demand refresh button. Reports stay readable during the refresh.
24 months of data retention in the analytics store. Older data drops off; it is not archived anywhere you can get at.
The reports carry a Last updated stamp rendered in the viewing user's time zone preference, and a Time zone filter that re-slices the data. Two supervisors can legitimately see different daily totals.
If an organisation goes unused for 30 days the refresh pauses; at 60 days of inactivity the analytics feature is deprovisioned entirely. Sandboxes that sit idle between sprints hit this.
Access is driven by read privilege on the report entity msdyn_dataanalyticsreport_csrmanager. System Administrator and CSR Manager get it out of the box; anything custom needs the privilege granting explicitly.
Standard filters are Duration, Channel, Queue, Agent and Time zone. Business Unit is not there by default — it only appears if you go through data model customisation.
The Summary and Agent reports are customisable in the embedded Power BI editor. Knowledge analytics and the old unified routing reports are not.

When to use / skip

Switch it on. It costs nothing beyond the toggle, it is the only supported first-party case reporting Microsoft still ships, and the alternative — hand-rolled Power BI over the incident table — is a week of work you will then own forever.

Where it falls down is depth. Two reports and a fixed 24-hour refresh will not satisfy a service desk that has been running Excel exports with twenty bespoke measures for a decade. If the client's reporting requirement runs to a document rather than a conversation, treat the out-of-box reports as the supervisor's day-to-day view and plan a separate custom reporting stream — either the embedded editor for light changes or the Fabric data model route for real ones. Do not promise the out-of-box reports will replace their existing MI pack, because they will not.

Skip it entirely only if the environment is a pure integration or data-migration workload with no human supervisors, or if the client has already built and accepted a Fabric-based reporting layer over Dataverse.

Configuration decisions

Whether to enable at all in each environment. Enabling in dev and test burns the 24-hour cycle on data nobody trusts, and idle sandboxes get deprovisioned anyway — most projects enable in production and one long-lived test environment only.
Which security roles get read on msdyn_dataanalyticsreport_csrmanager. Decide early whether team leaders see the Agent report or only the service manager, because the Agent report names individuals.
Whether business unit needs to appear as a filter. If the client is a multi-brand or multi-country shared service, you need that decision before you promise anything about scoping, since it pulls in data model customisation.
Which time zone the organisation reports in, and whether you enforce it via user preferences or leave supervisors to pick per session.
Whether case categorisation happens through out-of-box case fields (subject, case type) that the reports already group by, or through a custom field that the reports will not see without model work.
Whether the 24-month window is enough for the client's year-on-year comparisons, and if not, where the longer history lives instead.

Gotchas

Enabling the toggle historically also switched on AI topic clustering for cases with default settings. That clustering was removed on 31 August 2025, so the Topics report is no longer part of what you get, whatever older documentation and older demo decks imply. Check what the environment actually shows before you present it.
Custom columns on the case table do not appear. The semantic model is fixed unless you take the Fabric customisation route, and consultants routinely discover this after the client has already agreed their reporting requirements around a custom "root cause" option set.
The first refresh after enablement is not instant, and Microsoft does not surface a progress bar. Enable it several days before any demo or UAT session that depends on it.
The 24-month retention applies to the analytics store, not Dataverse. Deleting or bulk-archiving cases in Dataverse does not retroactively rewrite what the reports already aggregated, and equally, cases you migrate in with historic created-on dates may not populate history the way the client expects.
Time zone filters plus the user's own preference means "why does my number differ from yours" is a guaranteed support ticket in the first month. Agree one reporting time zone and write it down.
Report customisations published in the embedded editor are visible to everyone in the organisation, not just the person who made them. There is no per-user or per-role version of a report.

Consultant notes

Demo the Summary report against migrated or seeded data in a real environment, never a Microsoft sample tenant. The client's first question is always "where is my field", and you want that conversation in discovery, not UAT.
Tell the client plainly in week one that out-of-box analytics is two fixed reports refreshed daily. Every unhappy analytics conversation I have seen started with an unstated assumption of real-time, custom-field reporting.
Check the report entity privileges as part of your go-live security review. Supervisors seeing a blank page on day one because a custom role missed one read privilege is a very common and very avoidable escalation.
If the client has any appetite for custom measures, get the Fabric prerequisites (tenant settings, Entra security group, licences) raised with their Power BI admin early. That approval chain is usually the long pole, not the build.

Worth another look after the next wave, since the Topics report and the enable toggle's side effects have already changed once.