What it does
The admin portal is where tenant-wide configuration and oversight live — tenant settings, capacity settings, workspaces, embed codes, organisational visuals, domains, refresh summary and custom branding. Around it sit the admin monitoring workspace, the monitoring hub, the Capacity Metrics app and the admin REST APIs.
Key facts
- You need a Fabric licence and a Fabric admin role to open the admin portal. Without one you only see Capacity settings.
- The admin monitoring workspace installs itself the first time an admin opens it. Reports are blank until the first refresh, which starts about five minutes after installation. It carries the feature usage and adoption report plus its semantic models.
- The admin monitoring workspace is read-only. Items can't be edited, build permission shows as read, and private links and GDAP aren't supported.
- Its semantic models refresh once per day, around the time the workspace was first installed. If the admin who installed it loses the admin role, refreshes fail — another admin signing in fixes it. If that admin uses PIM, their access must be active at refresh time.
- Once access to the admin monitoring workspace is granted it can't be removed without reinitialising the workspace via the admin API.
- The monitoring hub shows activities per experience, including failures, submitter and duration.
- The Capacity Metrics app shows consumption in capacity units and is where capacity ID and name live when they're missing from audit logs.
- The scanner APIs — GetModifiedWorkspaces, PostWorkspaceInfo, GetScanStatus, GetScanResult — pull item metadata across the tenant: names, owners, sensitivity labels, tags, endorsement status, and for semantic models the tables, columns, measures, DAX expressions and mashup queries.
- Metadata scanning needs no special licence and covers non-Premium workspaces too.
- Scanner apps authenticate with either a delegated admin token or a service principal, and the two paths are mutually exclusive. A service principal app must have no Power BI admin-consent-required permissions set on it.
When to use / skip
Every tenant past about twenty makers needs a monitoring answer, and the built-in monitoring workspace is a reasonable starting point that costs nothing. Build a custom solution on the scanner API and the activity log when the client needs history beyond the built-in retention, needs to join usage to their own reference data, or has a compliance requirement with a named report. Don't build a bespoke tenant inventory before you've shown them the feature usage and adoption report — it answers more questions than people expect, and it's already there.
Configuration decisions
- Which admin installs the monitoring workspace, given that the account is baked into the refresh schedule and the PIM behaviour.
- Whether the monitoring workspace stays Pro-licensed or gets reassigned to capacity so it can be shared without per-user licences.
- Whether metadata scanning runs under a service principal or a delegated admin, and where the extracted metadata lands.
- Scan cadence, and whether you're doing full scans or driving off GetModifiedWorkspaces.
- Which admin capabilities are delegated to capacity, workspace and domain admins so central admin isn't a queue.
Gotchas
- Adding API permissions to the scanner app's Entra registration breaks service principal scanning. It's the same trap as embedding, and the error doesn't point at it.
- The monitoring workspace refresh failing because the original admin lost their role, or their PIM window closed, is a silent failure — the reports just get stale.
- Access to the monitoring workspace is one-way. Granting a stakeholder viewer access is not something you can undo without reinitialising, so think before you share.
- The monitoring workspace is still a preview capability. Don't build a compliance process that depends on it without a fallback.
- Capacity ID and capacity name aren't always present in audit logs, so a usage report joined on capacity will have gaps unless you pull them from the Metrics app.
Consultant notes
- Ship a monitoring answer as part of the platform build, not as a phase two. Clients who can't see what's happening in their tenant lose confidence in the platform, whatever the reports look like.
- Scanner API output is the basis for the conversations that actually change behaviour — orphaned models, unlabelled content, duplicate reports, workspaces with no owner. Get one extract in front of the client early.
- Warn the client that the admin monitoring workspace's dependency on a single installing admin is a real operational risk, and put a named alternate in the runbook.
- Delegate. The fastest way to make Power BI look bureaucratic is to route every capacity and workspace request through one person.
Worth revisiting once the admin monitoring workspace comes out of preview, or if the scanner API metadata set expands.