Analytics report data model and mapping

What it does

Microsoft publishes the star schema behind the out-of-box analytics reports — the fact and dimension tables, their attributes, and which report page maps to which table. It is the reference you need before you promise a client any custom measure, because it tells you what is in the semantic model and, by omission, what is not.

Key facts

The Customer Service manager analytics model is a classic star schema: FactCase at the centre, with DimDate, DimQueue, DimSystemUser, DimCaseProperty, DimTopic and DimTimeZone hanging off it.
FactCase carries the case-level measures — status, escalation, CSAT, resolution time. Everything the Summary and Agent reports show is derived from it.
DimCaseProperty is where status, priority, channel and case age buckets live. If a client asks to group by something case-shaped, this is the first place to look.
Standard measures include incoming, total, resolved, active, cancelled and escalated cases, escalation rate, average resolve time in hours, case age in days, first response SLA percentage, CSAT and sentiment.
Case data in this model is Customer Service only. The conversation-shaped models — FactConversation, FactSession, FactAgentStatusHistory — sit in the omnichannel analytics model and belong to the Contact Center and Omnichannel side of the world.
Microsoft names the PBIX behind each model in the documentation, which is how you tell which report set you are actually looking at when several are enabled in one environment.
DimTopic still exists in the published model even though legacy case topic clustering was removed in August 2025. A dimension being present in the schema is not proof the feature that populates it is alive.
The model is aggregated at multiple grains — by date, queue, topic and agent — with hour-level granularity available on the date dimension.
Reporting runs against the analytics store, refreshed every 24 hours with 24 months of retention, not against live Dataverse rows.
Custom Dataverse tables and columns are absent from this model by default. Adding them means the Fabric data model customisation route, not a change here.

When to use / skip

Read the model before any conversation about custom reporting, and before you answer "can we report on X". Nine times out of ten the answer is visible in the attribute list in about two minutes, and being able to say "yes, that is DimCaseProperty" or "no, that would need model customisation" in the workshop rather than a week later is most of the value a consultant adds on analytics.

You also need it when you are designing case data itself. If you know FactCase and DimCaseProperty are the reporting surface, you configure priority, case type and channel as proper option sets rather than free text, and the reports work for free. Teams that design the case form first and think about reporting later end up with three custom fields that never appear in a report.

Skip the detail if the client has accepted the out-of-box reports as-is and has no analytics backlog. The schema is reference material, not something you configure.

Configuration decisions

Which case attributes carry the reporting cut the client cares about, and whether those map onto the dimensions that already exist rather than new custom fields.
Whether the standard measures — escalation rate, average resolve time, first response SLA percentage — match the client's own definitions of those metrics. They frequently do not, and the gap needs naming early.
Whether you accept the model's grain. Hour-level date granularity is fine for most; anything finer means a different approach entirely.
Whether the client's CSAT comes from the survey source the model expects, or from a third-party survey tool that will never appear in FactCase.
Whether business unit needs adding as a dimension, which is a data model customisation decision with its own prerequisites.
Which report set the client is actually being shown, since several models can be provisioned side by side in one environment and they use overlapping report names like Summary and Agent.

Gotchas

Metric definition mismatches are the single most common analytics dispute. "Average resolve time" in the model has a specific calculation; the client's existing MI pack almost certainly has a different one, including or excluding on-hold time. Compare the definitions in writing before go-live.
Dimensions present in the schema do not guarantee working features behind them — DimTopic is the current example. Check the environment, not the schema.
The model reports on the analytics store, so anything that changes in Dataverse after the last refresh is invisible. Supervisors comparing a report to a live view will always find a discrepancy, and it is not a bug.
Custom option set values added after go-live flow through as new dimension members, but custom columns do not appear at all. Clients hear "the reports pick up our data" and assume both.
Case merges, deletions and bulk data operations do not neatly rewrite already-aggregated history. Plan any data cleanup with that in mind.
The conversation-side facts look tempting when a client has chat, but they belong to a separate model with separate enablement and separate licensing. Do not blend the two in a design document without saying which is which.

Consultant notes

Bring the attribute list to the reporting workshop. Walking a client through the actual dimensions turns a wish list into a scoped conversation in one session.
Write down the client's definition of each headline metric next to Microsoft's. That one table has saved more go-live arguments than any amount of report building.
Use the model to steer case design decisions early — option sets over free text, standard fields over custom ones wherever the reporting need is real.
Check which models are provisioned in the environment before demoing. Two Summary reports from different models, shown in the same session, will confuse everyone including you.

Worth checking again after each wave, since Microsoft adds measures and dimensions to these models without much fanfare.