Sooner or later every BI team gets the question — from an auditor, a security review, or a new CIO: "What exactly do we have in Power BI?" How many workspaces, which reports, whose semantic models, connected to which data sources, shared with whom. Most tenants cannot answer it, because Power BI itself never shows you the whole estate in one place.
What a real inventory must cover
- Workspaces — including admin-only ones you are not a member of, and the (usually enormous) pile of personal "My Workspaces".
- Reports — standard and paginated, with the workspace and app they are published through.
- Semantic models — owner, refresh schedule, refreshability.
- Apps and their audiences — who content is actually shared with.
- Capacities — which workspaces run on which SKU.
- Data sources — what each model actually connects to (the lineage layer).
Method 1 — The admin portal
The Fabric admin portal lists workspaces tenant-wide and exports them to CSV. It is the fastest first look, but it stops at the workspace level: no report list, no model detail, no data sources, no usage. Treat it as a headcount, not an inventory.
Method 2 — PowerShell and the admin REST APIs
The admin cmdlets and REST endpoints go much deeper — every workspace with its contents, tenant-wide report and app catalogs:
Login-PowerBI # admin account or service principal
# Every workspace in the tenant, including ones you are not in
Get-PowerBIWorkspace -Scope Organization -All
# Tenant-wide report catalog (REST, paged with $top)
Invoke-PowerBIRestMethod -Method Get -Url "admin/reports?`$top=5000"Method 3 — The scanner (metadata) API
For deep metadata at scale Microsoft provides the scanner API: you submit batches of up to 100 workspaces, poll for the scan to finish, and receive detailed metadata — including model tables and data sources — with an incremental "modified since" mode for follow-up scans. It is the most complete DIY foundation, and also the most work: a stateful pipeline with batching, polling, incremental bookkeeping and schema drift, all maintained by you.
The audit angle: inventory needs history
An auditor rarely asks "what exists today?" alone. The follow-ups are "when did this appear?", "who could see it in March?", "why did this workspace disappear?". Point-in-time exports cannot answer those — you need a catalog that records changes over time and marks deletions instead of erasing them.
What a continuous catalog adds
PGR Sonar syncs the whole estate on schedule: workspaces (member and admin-level, personal ones flagged as such), reports, semantic models with refresh schedules, apps with their access lists, capacities and data-source lineage. Deleted items are soft-marked rather than dropped, so the catalog keeps answering "what changed since the last audit" — and because usage and refresh history live in the same store, the inventory is joined to how content actually behaves, not just that it exists.