Review Report

Reviewing Power BI Reports

Structured evaluation of Power BI reports to produce actionable feedback for developers and consultants. A report review assesses whether a report is effective, well-built, and actually being used. The output is a prioritized list of findings with concrete recommendations.

Note that the skill works on one of three scenarios:

1. Report under development: In this scenario, the focus is more on the report content, structure, organization, and performance based on accurately gathered requirements.
2. Report in testing: In this scenario, the focus might incorporate user feedback or check basic information about the deployed report in Power BI / Fabric.
3. Report in use: This is the ideal scenario, where the focus is usage; the ultimate definition of success is whether the report is being used; what percentage of the people who have access to the report have accessed it in the last 28 days, and how much? Bad reports aren't used, or have declining usage.

In scenario 2-3 you may still provide feedback on the report content / structure, but prioritizing other things first.

When to Use

Activate when conducting a report review, audit, or health check. Common triggers:

• Reviewing report quality before a release or handoff
• Assessing whether existing reports are worth maintaining
• Identifying optimization opportunities across a workspace
• Evaluating report design and data presentation effectiveness
• Investigating report performance issues

Review Dimensions

A comprehensive report review evaluates six dimensions. Not every review needs all six -- scope to what the user needs.

1. Usage and Adoption

The most objective signal of report value. A report that nobody views is a maintenance liability regardless of its design quality.

Retrieve usage data with the scripts in scripts/:

# Workspace overview (views, rank, page views, load times)
python3 scripts/get_report_usage.py -w <workspace-id>

# Add Tier 3 cross-workspace last-visited timestamps via the undocumented DataHub V2 API
# Useful for the "is this report being used at all" question without tenant admin role
python3 scripts/get_report_usage.py -w <workspace-id> --include-datahub

# Single report deep-dive (daily views, per-viewer breakdown, page views by day)
python3 scripts/get_report_detail.py -w <workspace-id> -r <report-id>

# Distribution audit (who has access, through what channels)
python3 scripts/get_report_distribution.py -w <workspace-id> -r <report-id>

Filtering viewers: Exclude non-consumer users from adoption metrics. Service principals (type App), report developers, and IT / support personnel inflate viewer counts and distort reach. See references/usage-metrics.md for identification heuristics and references/distribution.md for resolving security groups and distribution lists via the Microsoft Graph API.

Evaluate usage signals:

• Audience reach is the most important metric: what percentage of users with access have actually viewed the report in the last 7, 28, and 60 days? See references/distribution.md for how to calculate reach and what the numbers mean
• View trends: Is viewership stable, growing, or declining? Use the rolling 7D average (see references/usage-metrics.md)
• Page view distribution: Are views concentrated on one page or spread across the report? Before calling a page unused, check whether it is a tooltip/drillthrough target (no direct views expected) and confirm reachability via pbir pages list
• Last visited: When was the report last accessed by anyone? Tier 1 (Admin Activity Events, 30-day rolling, admin role required) is the official path. The Tier 3 DataHub V2 lastVisitedTimeUTC field (--include-datahub) is the non-admin cross-workspace fallback; flag to the user it's undocumented and can break
• Load times: Are P50 and P90 load times acceptable for the audience? See references/performance.md for interpretation

Do not use arbitrary thresholds for what constitutes "healthy" or "concerning"; these depend entirely on the report's audience, purpose, and lifecycle stage. A report for 3 analysts has different expectations than one for 300 executives. Match the review window to the report's cadence before drawing conclusions; see references/usage-interpretation.md for common misreads of the modern Usage Metrics report and the retire/keep/redesign decision framework.

Subscriptions are not views. Email subscriptions deliver report snapshots without generating view events. Check admin/reports/{id}/subscriptions (requires Fabric Admin) for active subscribers. A report with 0 views but active subscriptions is being consumed passively.

Use rolling 7-day averages for view trends. Raw daily counts are noisy. Compare the current 7D average to the prior 7D to identify trajectory. See references/usage-metrics.md for methodology.

Key insight: Reports with 0 views are not necessarily bad. They may be new, seasonal, consumed via subscriptions, or used via embedded scenarios not captured in telemetry. Cross-reference with last-visited timestamps. Prefer the Tier 1 admin Activity Events feed where admin access is available; fall back to the Tier 3 DataHub V2 path when it is not, while flagging that it is undocumented.

Permissions: Tier 1 (WABI) needs any workspace role. Tier 2 (model) needs workspace Contributor+. Distribution and subscription checks need Fabric Admin (tenant-level). See references/usage-metrics.md for the full permission matrix.

For additional context on the usage metrics dataset schema and available tables, see usage-metrics-dataset/.

2. Design and Layout

Evaluate the visual design and information architecture. Consult the pbi-report-design skill for detailed guidelines. Reference: Data Goblins Report Checklist.

Checklist:

• Page titles present and descriptive
• Visual spacing consistent (equal gaps between visuals and margins)
• Detail gradient followed (KPIs top-left, detail bottom-right)
• Color usage intentional and accessible (no gratuitous color, no red/green for colorblind users)
• Font family, size, and formatting consistent throughout
• Visual count reasonable (loosely 12-15 max per page, depends on complexity)
• No empty visuals (all visuals have field bindings)
• Theme applied (not default Power BI theme)
• Chart axes begin at zero (unless intentional)
• Default sort configured on all visuals
• Visual objects labelled clearly in the selection pane (grouped with descriptive names)
• Mobile layout provided if relevant audience
• Visual headers configured (disable when drill-down/through not needed)
• Interactions configured (cross-filtering/highlighting intentional, not default)
• Slicer 'Apply' buttons considered for performance-sensitive pages
• Synchronized slicers where required across pages

3. Data Model Binding

Evaluate the connection between the report and its underlying semantic model.

Checklist:

• Report connects to a published semantic model ("thin report") rather than embedding its own ("thick report")
• All field bindings resolve to existing model columns/measures
• Extension measures (thin report measures) used sparingly and only for report-specific logic
• No broken or orphaned field references
• Appropriate use of measures vs. columns in visuals (aggregation context)
• Separate filters are not active on visual-level

4. Performance

Assess report load time and visual complexity. Run the performance audit script:

python3 scripts/performance_audit.py -w <workspace-id> -r <report-id>

See references/performance.md for percentile interpretation, DAX query inference from visual field bindings, and common anti-patterns.

Key indicators: P50 and P90 load times, visual count per page, extension measure count. Visual count is a proxy; query cost per visual is the real driver. See references/performance-audit.md for the full cost model, how to interpret a Performance Analyzer export, DirectQuery report-layer tuning levers, and the interaction/navigation audit. Do not apply rigid visual-count thresholds without reading the cost model first.

5. Report Metadata and Governance

Assess the report's governance posture. See references/report-metadata.md.

Checklist:

• Thin report (connected to published model, not embedded thick model)
• Endorsement status appropriate for its audience (Certified for production, Promoted for team use)
• Sensitivity label applied if tenant policy requires it
• Part of a deployment pipeline if in a production workspace
• Distribution via workspace app or org app (not direct links or publish-to-web)
• Access granted via security groups, not individual users
• View-only access for consumers (Viewer role), edit access only for developers
• Export-to-Excel patterns reviewed for data governance risks (see references/export-to-excel.md)