The four objects (learn these before anything)
| Object | What it is | The question it owns |
|---|---|---|
| Report | The visuals — pages, charts, the thing users look at | Layout, interactivity |
| Semantic model (was 'dataset') | The DATA model behind reports: tables, relationships, DAX measures, the refresh schedule | Performance, correctness, refresh, row-level security |
| Workspace | The container that holds reports + semantic models + other items; where PERMISSIONS live | Who can see/edit |
| Capacity | The COMPUTE the workspace runs on (a Fabric F-SKU or legacy P-SKU) | Speed, cost, throttling |
The rename that matters: 'dataset' became 'semantic model' — same object, and it is where the real engineering lives. A report is a thin skin; the model is the product. 'The report is wrong/slow' is almost always a semantic-model problem (bad DAX, a heavy model, a failed refresh), not a visual one.
Fabric: the platform Power BI now lives in
Microsoft Fabric is the unified analytics platform; Power BI is one of its workloads (alongside data engineering, warehousing, real-time, data science), all sharing one storage layer (OneLake) and one capacity model (F-SKUs). Practical consequences even for a Power-BI-only shop:
- Your workspaces sit on Fabric capacity (F-SKU), the successor to Power BI Premium's P-SKUs — F-SKUs are the path for new deployments.
- Semantic models can now source from Fabric items (lakehouses, warehouses) directly — the data estate and the BI estate converged.
- The admin/governance surface is the Fabric admin portal with 170+ tenant settings (the governance module — and serv365 scans all of them).
The routing reflex
Slow report → semantic model (size, DAX, refresh) OR capacity (throttling). Can't see it → workspace role + the licensing rule (next concepts). Costs a fortune → capacity SKU + usage. Wrong numbers → the model's logic and its last refresh. Never debug the visual first.
What to watch (proofs)
- The estate as objects: the Fabric admin portal / REST admin APIs enumerate workspaces, their capacity, and their items — the map serv365's Fabric leg reads (171 tenant settings scanned).
- A model's health: its refresh history (success/failure/duration) and size — the first read for any 'slow/wrong' report.
- Workspace→capacity mapping: which workspaces run on which F-SKU — the cost and performance attribution table.
- Object provenance: a report's underlying semantic model (they can live in DIFFERENT workspaces) — 'who can see the data' follows the MODEL's workspace, not the report's.