Power BI and Microsoft Fabric tenants accumulate workspaces, semantic models, reports, apps, notebooks, lakehouses, warehouses, pipelines, dataflows, shortcuts, permissions, credentials, schedules, and external dependencies faster than a small platform team can review them manually. The visible problem is clutter. The operating risk is unowned content, excessive access, duplicated metrics, unsupported sources, unknown lineage, failed refreshes, unmanaged capacity consumption, and critical reporting that depends on a departed employee.
Datrick builds a managed governance queue from supported tenant evidence. AI can classify metadata, group similar exceptions, identify missing owners, summarize dependencies, and draft outreach. It cannot delete or archive content, revoke access, transfer ownership, alter tenant settings, block a workspace, apply a label, or approve an exception without deterministic policy checks and accountable authorization.
Do you have hundreds of workspaces, departed owners, duplicate semantic models, or reports nobody can safely retire? Datrick can establish a verified inventory and prioritize the first governance cycle.
Define the governance contract before collecting data
Agree which tenant, clouds, capacities, domains, workspaces, item types, identities, external users, and time period are in scope. Define business ownership, technical ownership, support ownership, security review, lifecycle states, inactivity windows, criticality, retention, legal hold, archive requirements, acceptable exceptions, and approval authority. A standard can vary by domain: a daily operational report and an annual regulatory pack should not share one inactivity rule.
| Governance domain | Required evidence | Example finding |
|---|---|---|
| Ownership | Workspace admins and contacts, item owner, identity status, business owner, technical owner, support group, and last attestation. | Orphaned workspace, departed item owner, one-person dependency, or no business accountability. |
| Access | Workspace roles, group and direct assignments, item permissions, Build, sharing links, apps, external users, service principals, and effective access. | Excessive admin role, stale user, direct grant sprawl, unsupported external sharing, or no least-privilege rationale. |
| Content and lineage | Item type, source, downstream consumers, endorsements, labels, app, subscriptions, refresh, gateway, capacity, and cross-workspace dependencies. | Duplicate model, unknown source, uncertified critical content, hidden consumer, or unsupported dependency. |
| Activity and adoption | Views, queries, exports, shares, refreshes, edits, deployments, API use, subscriptions, consumers, dates, failures, and seasonality. | Unused candidate, low adoption, active unendorsed report, dormant but scheduled workload, or suspicious activity. |
| Lifecycle | Environment, status, creation, last change, owner decision, retention class, hold, archive package, recovery test, and deletion approval. | Production content without release path, expired temporary workspace, or retirement candidate lacking recovery evidence. |
| Platform policy | Tenant settings, domain delegation, workspace settings, tags, capacity placement, Git or deployment integration, monitoring, and exceptions. | Inconsistent workspace pattern, unassigned domain, missing tags, manual production publishing, or unreviewed tenant exception. |
Build a tenant inventory that can survive change
Microsoft recommends metadata scanning APIs, commonly called scanner APIs, for tenant-level inventory because they return workspaces and their Power BI items with richer metadata than older workspace-only approaches. Collect raw responses before transformation so new fields are not silently discarded. Add schema monitoring, pagination, retries, rate handling, collection health, and an immutable extraction timestamp.
Join metadata to the Power BI activity log. The API offers a limited online history, commonly up to four weeks, so extract and retain it continuously when longer adoption or lifecycle analysis is required. Preserve raw events and transform later. Activity schemas vary by event and can evolve; a rigid extraction parser can lose evidence.
Inventory is not truth until reconciled. Compare API output with admin views, known capacities, domains, deployment pipelines, business registries, identity data, and owner attestations. Track scan failures and inaccessible workspaces. “Not returned” is not the same as “does not exist.”
Resolve ownership before enforcing lifecycle
Microsoft recommends at least two workspace administrators so one remains when the primary is unavailable. A workspace without an active admin is orphaned. Identify administrators, contacts, members, item owners, service identities, credential owners, and business owners. Compare users with current directory and workforce status while respecting privacy and employment-data controls.
When an owner leaves or has been inactive, Fabric items can stop functioning correctly. Ownership transfer can affect child items, credentials, refreshes, gateways, pipelines, and service connections. Map dependencies and validate the successor before takeover. Record who authorized the transfer, what changed, which credentials require re-entry, and how operation was tested.
Review effective permissions, not only workspace roles
Workspace Admin, Member, Contributor, and Viewer roles are only part of the permission model. Add item-level permissions, Build, app audiences, sharing links, external users, service principals, semantic-model permissions, OneLake security, source-system access, and policy restrictions. A user can lack a workspace role and still have access to an item.
Prioritize excessive administrators, departed users, direct assignments where groups are required, broad Build rights, external sharing, high use of per-item permissions, stale service principals, and access to sensitive or critical content. Do not revoke automatically from inactivity alone; confirm job role, ownership, subscriptions, embedded use, automation, and approved exceptions.
Build a supervised tenant-governance workflow
| Component | Responsibility | Production control |
|---|---|---|
| Tenant collectors | Collect metadata scans, activity logs, admin monitoring, capacities, domains, tags, settings, identities, costs, refreshes, and incidents. | Read-only service principal, secret rotation, pagination, retries, raw retention, latency, and collection health. |
| Governance graph | Connect workspaces, items, sources, reports, apps, users, groups, permissions, gateways, capacities, domains, and downstream dependencies. | Stable identifiers, edge provenance, scan time, confidence, and explicit unknown relationships. |
| Deterministic policy engine | Evaluates ownership, access, lifecycle, naming, tags, environment, endorsement, activity, refresh, capacity, and exception rules. | Versioned policies, domain scope, effective date, approved exceptions, and no model-generated rule. |
| AI governance analyst | Groups findings, summarizes dependencies, detects likely duplicates, proposes owner questions, and drafts remediation briefs. | Evidence citations, confidence, alternatives, sensitive-data redaction, and no write authority. |
| Attestation workflow | Routes findings to workspace, item, business, security, compliance, and platform owners for decision. | Named approver, due date, reminder, conflict handling, reason, exception expiry, and escalation. |
| Controlled remediation | Transfers ownership, adjusts access, updates metadata, archives, retires, reassigns capacity, or fixes operational dependencies. | Approval, dependency precheck, backup or definition export, rollback, change window, and independent validation. |
| Evidence and reporting | Records findings, decisions, changes, failures, exceptions, recovery tests, risk reduction, adoption, and recurring backlog. | Immutable audit trail, tenant isolation, retention, access controls, and reconciled outcome. |
Retire content from evidence, not view count alone
Microsoft's lifecycle guidance recommends analyzing unused or occasionally used content at report, workspace, capacity, or domain level and choosing a time window appropriate to the business purpose. Three months can be reasonable for some quarterly content; a daily operational report may need attention after one month. Annual, regulatory, disaster-recovery, embedded, export-driven, or subscription-delivered content needs different evidence.
Before retirement, check views, queries, refreshes, subscriptions, exports, apps, sharing, embedded use, lineage, downstream models, Excel connections, APIs, source dependencies, sensitivity, legal hold, retention, owner attestation, and business calendar. Identify whether “unused” means inaccessible, undiscoverable, duplicated, broken, or genuinely unnecessary.
Use explicit states such as active, under review, owner required, remediate, consolidate, archive candidate, archived, retire approved, retired, hold, and exception. Require an archive package or supported recovery method where policy requires it. Test restoration before bulk cleanup. Record identifiers, definitions, dependencies, permissions, credentials that cannot be exported, owner, approval, deletion date, and recovery window.
Use domains and tags to support federated accountability
Fabric domains organize workspaces and enable parts of governance to be delegated to domain administrators. Tags add metadata for cost allocation, lifecycle, criticality, environment, owner group, support tier, and policy enforcement. A taxonomy is useful only when values have definitions, owners, allowed transitions, and quality checks.
Do not classify thousands of items with AI-generated tags and treat the result as governance. AI can propose values from names, lineage, activity, and owners. Require deterministic validation for fields that drive access, retention, cost, or enforcement. Track unassigned workspaces and stale or contradictory metadata as a backlog.
Operate a recurring governance cycle
- Collect and reconcile tenant, identity, activity, lineage, capacity, cost, and policy evidence.
- Detect new, changed, orphaned, overprivileged, inactive, unsupported, unlabeled, duplicated, failed, or unusually costly content.
- Prioritize by business criticality, sensitivity, external exposure, operational failure, capacity impact, age, and owner status.
- Send evidence-backed attestations with a proposed action, alternatives, deadline, and exception path.
- Execute approved ownership, access, metadata, consolidation, archive, or retirement changes through controlled runbooks.
- Verify effective access, refresh, apps, downstream consumers, capacity, archive recovery, and stakeholder outcomes.
- Report unresolved ownership, expired exceptions, policy coverage, risk reduction, adoption, cost, and recurring failure.
Monthly governance is often appropriate for high-change tenants, with quarterly business-owner attestations and event-driven handling for leavers, critical failures, external sharing, and tenant-setting changes. The cadence should match risk and change volume rather than produce meetings without action.
Measure risk reduction and enablement together
- Ownership: workspaces with two active admins, items with accountable owner, orphan age, takeover completion, and single-person dependencies.
- Access: excessive admin and Build permissions, stale direct grants, external exposure, exception age, and verified revocation.
- Lifecycle: classified content, owner response, archive candidates, successful recovery tests, approved retirements, failed changes, and backlog age.
- Operations: refresh failures, unsupported sources, credential-owner gaps, capacity hotspots, duplicate models, and unowned incidents.
- Adoption: active consumers, critical report use, certified-content share, duplicate reduction, discoverability, and user support demand.
- Control: unauthorized deletion, broken dependency, lost recovery path, access exposure, incorrect classification, and unsupported automated decision.
Do not celebrate deletion count. A healthy program reduces risk and noise while preserving useful, trusted content and enabling teams to publish through clear patterns. Track time from finding to accountable decision and the recurrence of the same governance failure.
Run a three-to-six-week tenant governance assessment
- Define tenant scope, stakeholders, business domains, policy sources, target outcomes, data handling, and change authority.
- Configure read-only admin and metadata access, preserve raw scans and activity, and establish collection health.
- Build the workspace, item, ownership, access, source, lineage, capacity, domain, activity, and lifecycle inventory.
- Reconcile identities, administrators, contacts, service accounts, gateways, credentials, and business owners.
- Apply versioned finding rules and rank orphaned, excessive-access, inactive, duplicated, unsupported, failed, and costly content.
- Validate a sample with workspace, business, security, and platform owners; measure false positives and missing evidence.
- Run one controlled remediation wave with dependency checks, approval, archive or rollback, and post-change validation.
- Deliver the governance baseline, prioritized backlog, ownership matrix, lifecycle policy, operating runbooks, dashboards, managed-service cadence, and acceptance measures.
Assessment length depends on tenant size, API access, retained activity, identity quality, lineage, external sharing, and owner responsiveness. Begin with a bounded domain or capacity if the tenant is large. The first cycle should prove that findings lead to safe decisions, not attempt bulk deletion.
Frequently asked questions
How do you govern a Power BI or Microsoft Fabric tenant?
Establish a tenant inventory from supported admin and metadata APIs, retain activity evidence, assign accountable workspace and item owners, define workspace and domain standards, review effective permissions, classify criticality and lifecycle state, monitor exceptions, and use approved archive or retirement workflows. Governance should enable supported self-service while making ownership and risk visible.
How do you find orphaned Power BI workspaces and Fabric items?
Compare workspace roles and contacts with the current identity directory and HR or contractor status, then identify workspaces without an active accountable administrator and items owned by departed or inactive users. Validate dependencies, credentials, schedules, child items, apps, external consumers, and business ownership before transferring ownership or changing access.
Can unused Power BI reports be deleted automatically?
Deletion should not be based on view count alone. A report can support infrequent financial, regulatory, operational, embedded, export, subscription, or disaster-recovery use. Combine an approved inactivity window with lineage, refresh, sharing, app, export, subscription, dependency, criticality, owner attestation, archive evidence, recovery testing, and a reversible decision workflow.
What data is needed for a Power BI tenant governance assessment?
Useful evidence includes metadata scanner output, workspace and item inventory, roles and effective permissions, tenant settings, domains and tags, activity logs, refresh and capacity evidence, lineage, endorsement and sensitivity labels, data sources, apps, subscriptions, external sharing, identity status, costs, incidents, and owner attestations.
How long does a Power BI tenant governance assessment take?
A focused assessment can often produce a verified inventory, risk segmentation, and prioritized remediation in three to six weeks when admin API access, identity data, activity history, governance policies, and owners are available. Remediation and a recurring managed governance cycle depend on tenant size, lineage, access complexity, business attestation, and archive requirements.
Official implementation references
- Microsoft Power BI tenant-level auditing guidance
- Microsoft Power BI activity log guidance
- Microsoft Power BI content retirement and archive planning
- Microsoft Power BI content creator security planning
- Microsoft Fabric item ownership takeover
- Microsoft Fabric domains
- Microsoft Fabric tags
Start with one domain, capacity, or high-risk workspace group. Datrick can build the inventory, validate ownership and permissions, rank lifecycle findings, and operate a controlled remediation cycle.