How to find unused Power BI reports across multiple workspaces

A list sorted by view count is useful, but it is not a retirement decision. A quarterly finance report may be essential even when it has no activity for weeks. A heavily viewed report may still be redundant. And a report absent from a native usage view may be old, newly created, inaccessible to the reviewer, or simply outside the available activity window.

The practical goal is therefore not to find reports with the smallest number. It is to build a review queue with enough evidence for an owner to choose: promote, improve, consolidate, monitor, archive, or retire.

Why this becomes difficult across workspaces

Power BI’s usage metrics are useful for understanding activity in a workspace. Microsoft documents that the classic usage metrics report contains 90 days of data and only includes reports or dashboards accessed during that period. Microsoft also explains that you can remove the report filter from a saved copy to compare content within the current workspace.

That workspace scope is where portfolio work starts to become operationally expensive. A platform owner reviewing 40 workspaces should not have to open 40 separate reports, apply slightly different filters, and manually reconcile names in a spreadsheet every month.

There are also legitimate differences between usage metrics and audit activity. Microsoft notes that usage metrics are collected on the client and can undercount when network conditions, blockers, or other issues disrupt the event. Treat every source as evidence with a defined boundary—not as an infallible ledger.

For a current breakdown of retention, permissions, page telemetry, and exclusions, review the Power BI Usage Metrics limitations guide.

A seven-step process that works at portfolio scale

1. Start with inventory, not activity

Create a current inventory for the workspaces in scope. At minimum, retain:

• workspace name and stable workspace identifier;
• report name and stable report identifier;
• report owner or accountable business contact;
• created and last-modified dates where available;
• distribution context, such as an app or direct sharing;
• status, including active, under review, archived, or retired.

Stable identifiers matter because names change and duplicate report names are common across departments. If your review begins with activity alone, content with no qualifying events can disappear from the analysis—the exact content you are trying to find.

A mature inventory also needs accountable business and technical owners. See what usage data cannot tell you about report ownership.

2. Choose and publish one evidence window

Define the window before calculating inactivity. For example, your policy might require 180 days of retained history before a report can enter review, with a longer exception for annual or regulatory content.

The window should be visible in the result. “0 views” is incomplete. “0 recorded views from February 1 through July 30 across the selected workspaces” is evidence an owner can interpret.

If your source only exposes a shorter window, preserve each collection in storage you control. A rolling source cannot answer a long-term question after its oldest events expire unless you retained them earlier.

3. Measure more than total views

Combining these signals helps distinguish a dormant report from a narrow but loyal one. It can also reveal reports that need improvement rather than retirement: declining activity paired with slow openings, for example, deserves investigation.

4. Apply the same inactivity rule everywhere

Use one definition across all selected workspaces. A defensible first-pass rule might be:

Flag active inventory items with no recorded views and no unique viewers during the approved evidence window.

Add explicit exception flags for annual processes, regulatory evidence, executive or board reporting, disaster recovery, and newly published content. Do not hide exceptions in someone’s memory; make them reviewable fields.

5. Add business and ownership context

Usage data can tell you what happened. It usually cannot tell you whether a report is the official record, whether an audit requires it, whether a replacement exists, or who should approve a change.

For every flagged item, identify an accountable owner and ask:

• What decision or process does this report support?
• Is there a replacement, duplicate, or certified alternative?
• Is its usage seasonal, annual, or event-driven?
• Does another report, subscription, export, or process depend on it?
• How quickly could the item be restored if the decision is wrong?

6. Use a staged outcome, not immediate deletion

Microsoft’s lifecycle guidance recommends identifying content that is no longer used, validating whether it should be retired, communicating planned changes, and defining an archival approach. That sequence is safer than turning a low-use filter into a delete button.

1. Review: assign the item to an owner with the evidence window and reason it was flagged.
2. Warn: communicate the proposed outcome and a response deadline to known stakeholders.
3. Archive or quarantine: preserve the file, settings, ownership, and decision record according to policy.
4. Observe: allow a defined recovery period before permanent removal.
5. Retire: remove the item only after approval and dependency checks are complete.

7. Keep a decision log

Record the evidence window, reviewer, owner response, exception, decision, approval date, archival location, and planned deletion date. The log makes the process repeatable and prevents the same report from being rediscovered and debated every quarter.

What the final review queue should show

A useful portfolio page should let a reviewer move from the estate to a report without losing context. Include workspace, report, views, viewers, last activity, trend, owner, exception, review status, and proposed action. Show the evidence period prominently and make filtering consistent.

Do not label the page “Reports to delete.” Label it “Inactivity and retirement review.” The name reinforces the correct behavior: the analytics starts a governed decision; it does not make one.

Where UsageVault fits

UsageVault is built for teams that want one maintained Power BI model across selected workspaces, with report, page, audience, opening-performance, and inactivity signals retained in their own SQL environment. It reduces the recurring collection and reconciliation work and gives reviewers a consistent starting point.

It does not know your business criticality, certify that every dependency is safe, or replace owner approval. Your team still defines the policy and makes the retirement decision. That boundary is intentional.

Primary sources

• Microsoft Learn: Monitor report usage metrics
• Microsoft Learn: Retire and archive Power BI content
• Microsoft Learn: Tenant-level auditing and monitoring