Power BI Reporting Project Checklists

Actionable checklists (checkboxes) to run an end-to-end reporting project: scoping, design, build, acceptance testing, production rollout, operations.

Guide≈ 19 min readCheckedReading

At a glance

Actionable checklists (checkboxes) to run an end-to-end reporting project: scoping, design, build, acceptance testing, production rollout, operations.
An architecture choice checklist (OneLake / Fabric or managed SQL Server), a report review, and a model review to use in pair review.
Each list goes from foundation (🟢) to expert refinement (🔴); you can trim it down based on project size.
How to use: copy the list into your tracking tool (tasks, wiki), remove what does not apply with justification, and keep a record of checked items as evidence.
How to interpret the case file (OneLake + SaaS mobile apps; managed SQL Server): see the folder README.

On this page

1. How to use these lists
2. Phase 1 — Scoping
3. Phase 2 — Design
4. Phase 3 — Build
5. Phase 4 — Acceptance Testing
6. Phase 5 — Production Deployment
7. Phase 6 — Operations
8. Architecture selection checklist
9. Report review
10. Model Review
11. Passing Threshold and Reading Results
1. 🟡 Practical — Scoring a Review
2. 🔴 Expert — Link to the Matrices
12. AI Contribution
13. See Also

Level: 🟢→🔴

1. How to use these lists#

🟢 Novice — Proper use#

A box is checked with evidence (link, screenshot, query result), not “because it’s roughly done.”
A non-applicable item is crossed out with a reason (“NA — no personal data”), never silently deleted.
These lists are safeguards, not a process: they complement a method (Scrum Applied to Data, BI, and Datamarts, Methods Specific to Data Projects) without replacing it.

🟡 Practical — Scale to size#

Project size	What to keep
Small (one report, one author, < 30 users)	Items marked [S] (foundation) in each phase
Medium (team of 3–8, multiple reports, RLS)	[S] + [M]
Large (shared models, multiple languages, external customers, compliance)	[S] + [M] + [E] (expert)

Legend: [S] foundation, [M] recommended, [E] expert. The items reflect the practices detailed in 10 — Cross-Cutting Power BI Best Practices; references § n point to its sections.

🔴 Expert — Make the checklist a living tool#

After each incident, add an item that would have prevented it (and, if possible, an automated control).
Remove items that have become automatic (CI): a checklist that grows endlessly is no longer read.
Measure: number of “NA” items per project, incidents avoided, review time.

2. Phase 1 — Scoping#

Goal: know for whom, to decide what, with which data, and by when.

🟢 Foundation#

[ ] [S] The decisions the reporting must support are written down (3 to 5 business questions, not a list of charts).
[ ] [S] A sponsor and a functional owner (who settles definitions) are assigned.
[ ] [S] Users are identified by profile (executive team, field manager, sales, support) and by device (desktop, mobile, tablet).
[ ] [S] The list of priority KPIs with a one-sentence business definition for each.
[ ] [S] Sources are listed (SaaS mobile app, SQL database, files) with an owner per source.
[ ] [S] The delivery scope (what is in and out) and one acceptance criterion per KPI.

🟡 Practical#

[ ] [M] Expected freshness per KPI (D-1, hourly, real-time) justified by a decision — not by principle.
[ ] [M] Estimated volume today and at 3 years (fact rows, number of entities), growth.
[ ] [M] Languages to support (interface, labels, data) and regional formats.
[ ] [M] Security: who sees what (draft role × scope matrix), personal data present, legal basis, and retention period.
[ ] [M] Licenses: viewers/creators, capacity, estimated recurring costs (orders of magnitude); see 09 — comparison.
[ ] [M] Constraints: network, data residency, mandated tools, timeline, available skills.
[ ] [M] Identified risks with owner (SaaS API quotas, source quality, adoption, single-person dependency).
[ ] [M] Existing reports to replace or run side by side; known consumers of current models (linked client reports).

🔴 Expert#

[ ] [E] Data contract with each source (fields, types, volume, frequency, schema-change notice period); see Data Sources and Data Contracts.
[ ] [E] Measurable success indicators for adoption (active users at 3 months, documented decisions) and quality (tolerated reconciliation gap).
[ ] [E] Definition of “done” for reporting: documentation, testing, training, planned operations.
[ ] [E] Assumptions and their validation deadlines.
[ ] [E] Evolution roadmap: what is planned at 6 and 12 months, so architecture is not frozen around today’s need.

⚠️ Pitfall

Symptom: “we’ll figure out the KPIs as we go.” Consequence: three definitions of “active customer” in acceptance testing. Fix: no KPI development without a definition signed by the functional owner.

🤖 AI

Useful for turning interview notes into a list of candidate KPIs and clarification questions; it does not decide a business definition.

3. Phase 2 — Design#

Goal: an architecture, a model, and a mockup validated before building.

🟢 Foundation#

[ ] [S] Conceptual model in star schema: fact tables (documented grain), dimensions, date table (§ 2).
[ ] [S] Storage mode chosen per table (Import, DirectQuery, composite, Direct Lake) and justified.
[ ] [S] Mockup (paper or one page) validated by a real user.
[ ] [S] Naming standard and model conventions written down (§ 3).
[ ] [S] Architecture selected via the architecture choice checklist.

🟡 Practical#

[ ] [M] Dictionary of priority measures: name, definition, plain-language formula, unit.
[ ] [M] Refresh strategy (trigger, window, dependencies, failure recovery, idempotency).
[ ] [M] Historization: which dimensions evolve (SCD), which reference date is used for figures.
[ ] [M] Security plan: roles, expressions, user-to-scope mapping table, workspace sharing (§ 6).
[ ] [M] Environments (development, acceptance testing, production), parameters per environment, non-personal test datasets (§ 11 of folder 10).
[ ] [M] Multilingual: source language, target languages, single source of truth for labels, sort by column (§ 9).
[ ] [M] Mobile: if usage is field-based, phone layout planned, KPI cards, offline evaluated.
[ ] [M] Capacity: estimated load (refreshes, concurrent users), margin.
[ ] [M] SaaS source: API quotas, pagination, token, drifting schema, delayed synchronized data (see 03 — OneLake + SaaS Mobile Apps: Challenges and Pitfalls).

🔴 Expert#

[ ] [E] Test plan designed along with the design (frozen KPI set, reconciliations, security matrix).
[ ] [E] Performance plan: budget per page (target time, number of visuals), timed scenarios.
[ ] [E] Model versioning strategy and backward compatibility (no measure deletion/rename without notice) (§ 13).
[ ] [E] Exposure layer (reporting views, gold tables) separate from technical tables.
[ ] [E] Exit plan (reversibility) documented: formats, proprietary dependencies.
[ ] [E] Architecture review by someone outside the project.

✅ Good practice

Have the mockup validated with anonymized real numbers: a chart with plausible values triggers feedback that fake data never triggers.

4. Phase 3 — Build#

Objective: build small, versioned, continuously tested.

🟢 Foundation#

[ ] [S] Source repository created: Power BI project (PBIP/TMDL), source scripts, documentation; cache file exclusions in place (§ 10).
[ ] [S] Each change is committed with a message that explains why.
[ ] [S] Heavy transformations are handled upstream (SQL / lakehouse), not in Power Query.
[ ] [S] Columns keep the source name; labels are handled through translations.
[ ] [S] One base measure per KPI; derived measures build on it.
[ ] [S] Relationships are single-direction, one-to-many; any exception is justified.

🟡 Practice#

[ ] [M] Query folding is verified for every imported table.
[ ] [M] Types are explicit, conversion culture is set.
[ ] [M] Unnecessary columns are removed; high-cardinality columns (timestamps) are split.
[ ] [M] Measures have description, format, display folder; technical columns are hidden.
[ ] [M] JSON theme applied; page template used; alternative text completed (§ 8).
[ ] [M] RLS implemented and tested by role from the start, not at the end (§ 6).
[ ] [M] Project syntax validation before each open/commit (TMDL check).
[ ] [M] Incremental refresh configured when data volume justifies it, and tested (no duplicates, no gaps).
[ ] [M] Translations generated by script from the label source, with completeness check.
[ ] [M] Peer review (model and report reviews below) before merge.

🔴 Expert#

[ ] [E] CI pipeline: syntax validation, good practice rules (Best Practice Analyzer), check “no existing lineageTag disappears,” check “one key per table,” translation completeness.
[ ] [E] Automated DAX tests on a fixed KPI set.
[ ] [E] Performance measurements logged (duration, formula/storage engine split) before and after each optimization.
[ ] [E] Aggregations / calculation groups documented (why, how to validate them).
[ ] [E] Idempotence verified: rerunning a load does not change the result.
[ ] [E] Observability: load log, failure alerts, volume per run.

⚠️ Pitfall

Symptom: “we'll do the security tests at the end.” Consequence: RLS exposes a model defect (relationships, keys) discovered too late to fix without redesign. Remedy: minimal RLS from the very first iteration.

5. Phase 4 — Acceptance Testing#

Objective: prove that the numbers are correct, security holds, and it is usable.

🟢 Foundation#

[ ] [S] Reference numbers: for each KPI, at least one verifiable number in the source (closed period).
[ ] [S] Reconciliation model ↔ source on totals (written tolerated variance).
[ ] [S] Security testing with a real reader account per role; at least one “user with no role” case and one “multi-role” case.
[ ] [S] User acceptance testing by a business representative; issues logged and prioritized.
[ ] [S] Refresh succeeds multiple times in a row, including after a simulated failure.

🟡 Practice#

[ ] [M] Data edge cases: null values, entities with no event, accented and special characters, time zones, end of month/year, source duplicates.
[ ] [M] Performance: each key page timed (desktop, mobile), under simulated load.
[ ] [M] Accessibility: contrast, keyboard navigation, tab order, alternative text (§ 8).
[ ] [M] Languages: each page checked in each language, correct sorting and formats.
[ ] [M] Mobile: main user journey on a real device, including degraded connection.
[ ] [M] Non-regression: fixed KPI set replayed and identical (or variance explained and accepted).
[ ] [M] Exports: what the user can export complies with the security policy.
[ ] [M] Acceptance testing doc: report with date, model version, testers, accepted variances.

🔴 Expert#

[ ] [E] Dual acceptance testing (old report vs. new) over a full period with explained variance report.
[ ] [E] Recovery test: stop mid-load, restart, identical result.
[ ] [E] Schema drift test: rename or add a source-side column, pipeline behavior and alerts.
[ ] [E] Capacity load test: reader peak during refresh; throttling observed or not.
[ ] [E] Failover test: if Direct Lake, verify effective mode (no unintended fallback to DirectQuery).
[ ] [E] Identity test: disabled account, guest user, scope change during the day.

🧪 Example

A paper-successful acceptance testing: 25 KPIs verified. The 26th, not listed, a “coverage rate,” varied by role. Added a per-role test for every ratio measure, now in the list.

6. Phase 5 — Production Deployment#

Objective: deliver without surprises and be able to roll back.

🟢 Foundation#

[ ] [S] Deployed artifacts are the ones from acceptance testing (same version, no rebuild).
[ ] [S] Production settings applied (sources, schedule), credentials in gateway/connection, not in code.
[ ] [S] Permissions: readers, authors, administrators; no consumer is a workspace member (RLS bypass).
[ ] [S] Scheduled refresh configured, failure notifications sent to a monitored mailbox.
[ ] [S] Rollback plan written and tested (previous version available).

🟡 Practice#

[ ] [M] Release notes (visible, breaking, and to-be-validated changes).
[ ] [M] Communication to users (date, new features, definition changes, support).
[ ] [M] Training or quick-start guide (one page), short video if helpful.
[ ] [M] Endorsement: content promoted/certified according to organization criteria (§ 12).
[ ] [M] Sensitivity label applied.
[ ] [M] App / distribution: Power BI app or report link depending on audience.
[ ] [M] Capacity: margin confirmed in production, active monitoring.
[ ] [M] Connected reports: known consumers informed; coexistence if model change.

🔴 Expert#

[ ] [E] Gradual deployment (pilot group, then expansion) with promotion criteria.
[ ] [E] Period freeze avoided (financial closings, campaigns) for delivery.
[ ] [E] Automated post-deployment verification (refresh OK, test queries, counts).
[ ] [E] Register: model version, source script version, date, owner, link to tickets; chained with project tracking (see CI/CD for Data: Databases, Datamarts, Pipelines, and Reports).
[ ] [E] Final security review (external sharing, embedding, labels).

⚠️ Pitfall

Symptom: “it worked in acceptance testing” but production shows blank numbers. Cause: role differences (acceptance testing done as administrator) or source differences (parameter not switched). Remedy: environment parameter checklist and final test with a real reader account.

7. Phase 6 — Operations#

Objective: sustain over time — reliability, evolution, retirement.

🟢 Foundation#

[ ] [S] Refresh monitoring: failure = alert, with owner and response time.
[ ] [S] Support: channel and owner identified; incident template.
[ ] [S] Backup/versions: versioned sources, restore tested at least once.
[ ] [S] Change log kept up to date.
[ ] [S] Owner identified for each report and each model.

🟡 Practical#

[ ] [M] Usage indicators: active users, viewed pages, unused reports (quarterly review).
[ ] [M] Capacity metrics: peaks, smoothing, rejections; sizing decisions documented.
[ ] [M] Data quality: checks after each load (volume, orphan keys, out-of-range values) and alerts.
[ ] [M] Change management: every change goes through the same flow (branch, review, acceptance testing, deployment).
[ ] [M] Periodic security review: up-to-date user-scope mapping, departed accounts, shares.
[ ] [M] SaaS source monitoring: announced API changes, quotas, certificates, tokens.
[ ] [M] Costs tracked (capacity, database, licenses) and compared to budget.
[ ] [M] User feedback collected (short survey, interviews) and addressed.

🔴 Expert#

[ ] [E] Service-level objectives (freshness, availability) measured and published.
[ ] [E] Post-incident analysis without blame; each root cause produces a checkbox or an automated control.
[ ] [E] Model debt: list of obsolete measures, unused columns, relationships to simplify; debt-reduction budget per quarter.
[ ] [E] Disaster recovery tests for the chain (database, capacity, repository).
[ ] [E] Annual architecture review: revisit the selection checklist with real usage and cost figures; see switch-over thresholds in the comparison.
[ ] [E] Retirement plan: criteria and process for archiving a report.

✅ Good practice

Plan operations from the scoping stage: reporting without an operations owner is reporting that quietly dies one day when a refresh failure goes unnoticed.

8. Architecture selection checklist#

To be completed before the design phase; supplement the comparison and its decision tree.

🟢 Foundation — Needs and constraints#

[ ] The 5 major non-functional requirements are quantified: freshness, volume (current, at 3 years), number of readers, availability, response time.
[ ] The source of truth for each entity is identified (SaaS application, SQL database, reference repository).
[ ] The real-time need is justified by a decision (“which decision changes in 5 minutes?”).
[ ] Available skills are listed (T-SQL, Spark/Delta, DAX, capacity administration).
[ ] Constraints on data residency, private network, and compliance are known.
[ ] The annual budget (licenses, database or capacity, people) is known in orders of magnitude.

🟡 Practical — Evaluation#

[ ] The /5 grid (freshness, performance, cost, complexity, governance, scalability, skills, maturity, lock-in) is completed independently by at least three people, then compared.
[ ] Criteria weights are decided before calculating the average.
[ ] A license calculation compares “per-user licenses” and “capacity” with the real number of readers (pricing verified as of date).
[ ] The pilot is defined: scope (3 to 5 tables, one report), duration (2 to 4 weeks), quantified success criteria.
[ ] The SaaS source is assessed: API quotas, delta mechanisms (cursor, modification timestamp), deletion handling, schema stability, offline data and sync delays; see 01 — OneLake + SaaS Mobile Apps: Overview.
[ ] The preview features the choice depends on are identified (GA/preview status verified as of date) and paired with a plan B.
[ ] Security is mapped by layer (source, lakehouse/SQL endpoint, model, report); see 06 — SQL Server in SaaS — Architecture and 02 — OneLake + SaaS Mobile Apps: Architecture.

🔴 Expert — Decision and reversibility#

[ ] The exit plan exists: raw data kept in an open format, portable processing, versioned models.
[ ] The coexistence path (for example managed SQL with mirroring to Fabric) is described: steps, criteria, source of truth by entity, coexistence exit criterion.
[ ] A switch-over threshold is written (“if refresh time > X or readers > Y, then reconsider”).
[ ] The decision is recorded in an architecture decision record (context, options, ratings, decision, consequences, review date).
[ ] The review is scheduled at 6 or 12 months with real measurements.
[ ] Lock-in risks (orchestration, capacity model, formats, tools) are listed with mitigations.

💡 Expert tip

Write the architecture decision as if it had to be explained to your successor in two years: what options, why this one, what would make us change our minds. That's the antidote to “why did we do this?”.

9. Report review#

To be done in pair review before delivery of each report (30 to 45 minutes). Rate each line OK / To fix / NA.

🟢 Content and readability#

[ ] The report answers the decision stated during scoping; the main page is understandable in 10 seconds.
[ ] Explicit titles for pages and visuals, in business language; the conclusion is readable in the title when relevant.
[ ] Units, periods, currency and last refresh date visible.
[ ] Accessible definitions (tooltip, “About” page).
[ ] Consistency: same colors for same categories, same number formats.
[ ] No overloaded page: one page = one question; about ten visuals at most.

🟡 Technical and usability#

[ ] Clear navigation (buttons, bookmarks), no orphan pages; test pages removed.
[ ] Filters: useful slicers, relevant initial state, reset button.
[ ] Interactions between visuals checked (cross-filtering as intended, disabled when misleading).
[ ] Performance: each page loaded under target; no visual returning thousands of rows.
[ ] Mobile: phone layout if mobile usage; device test.
[ ] Accessibility: contrast, alt text, tab order, information not conveyed by color alone.
[ ] Languages: labels and titles translated in all supported languages; local formats.
[ ] Theme applied, no local style bypassing the design system.
[ ] Exports and sharing compliant with policy; sensitivity label applied.
[ ] Custom visuals: certified or audited.

🔴 Reliability and governance#

[ ] Displayed figures are reconciled against a source figure for at least three KPIs.
[ ] The measures used come from the shared model (no local measure redefining a KPI).
[ ] Security has been tested with a reader account for each role.
[ ] The report is linked to the right model (production, not a development model); correct parameters.
[ ] The owner, date, and version are filled in; endorsement requested if criteria are met.
[ ] The test set (reference screenshots or KPI values) is attached to the review.

10. Model Review#

To be done as a peer review for every significant change to the semantic model (TMDL diff read line by line).

🟢 Structure#

[ ] Star schema: facts and dimensions are identifiable, grain documented for each fact.
[ ] Relationships one-to-many, single direction; any bidirectional or many-to-many relationship is justified in writing.
[ ] Date table dedicated, marked, continuous; inactive relationships for secondary roles.
[ ] Keys: integer, unique on the dimension side; a single key column per table.
[ ] Columns: no unnecessary columns; technical columns hidden; names identical to the source.
[ ] Naming complies with standards; display folders are consistent.

🟡 Calculations and Data#

[ ] Measures: description, format, display folder; no formula copy-paste (base measures reused).
[ ] DAX: variables, DIVIDE, filters on columns, no unjustified iterator, BLANK() rather than 0 when that is the intended meaning.
[ ] Ratios: numerator and denominator tested separately; denominator independent from unintended filters (RLS, facts).
[ ] Time intelligence based on the date table.
[ ] Power Query: folding verified, explicit types, culture fixed, no plaintext secrets, environment parameters.
[ ] Incremental refresh: foldable filter, reliable modified-date column, duplicate-free tests.
[ ] Integrity: no orphan keys in facts (or an “Unknown” row).
[ ] Cardinality: high-cardinality columns split or removed; model size within budget.

🔴 Security, Versions, Sustainability#

[ ] RLS/OLS: expressions reviewed; test matrix executed; behavior under inactive relationships verified.
[ ] lineageTag: no existing tag modified or missing; no measure deleted then recreated; additions with unique tags (§ 13).
[ ] Compatibility: no renaming or removal of public measure/column without notice and coexistence period.
[ ] Translations: each exposed object translated in each language; sort-by-column is consistent.
[ ] TMDL syntax validation passed; project opens in the tool.
[ ] Performance: key visual queries measured (formula/storage) before and after.
[ ] Storage mode: if Direct Lake, effective mode checked (no fallback); if DirectQuery, query plans verified on the source side.
[ ] Documentation regenerated; release notes written; breaking changes flagged.
[ ] Tests: frozen KPI set rerun, variances explained.

✅ Good practice

Run automatic checks first (syntax, tags, keys, translations), then reserve human review for what a script cannot see: business definition, readability, relevance of relationships, back-filtering risk.

11. Passing Threshold and Reading Results#

🟡 Practical — Scoring a Review#

Convert each line into progress: OK = 1, partial = 0.5, To fix = 0 (N/A lines are excluded). Calculate the rate by block (foundation, practical, expert).

Result	Interpretation	Typical decision
Foundation < 100%	A prerequisite is missing	Do not release: fix first
Foundation 100%, practical < 80%	Moderate risk	Release with a dated remediation plan
Foundation 100%, practical ≥ 80%, expert < 50%	Good project level	Release; schedule refinement
Practical ≥ 80%, expert ≥ 80%	Industrial-grade level	Release; target certified models

This scale follows the spirit of the common rule used in maturity matrices (a level is achieved at 80% with no milestone at zero): an item scored zero in the foundation blocks progress regardless of the average. These are guidelines, not dogma (see RATING).

⚠️ Pitfall

Goodhart's law: a checklist checked just to be checked protects against nothing. Countermeasures: require evidence for each item, run checks automatically, rotate reviewers, and randomly audit one item per review.

🔴 Expert — Link to the Matrices#

Phase / checklist	Matrix theme that measures the practice
Scoping	Scoping, Value, and Use Cases
Design and model review	Semantic Model
Build (DAX, data)	DAX Measures and Calculations · Data Layer and ETL
Acceptance testing	Testing and Metrics Reliability · UAT and Business Validation
Production deployment	Report Versioning and Industrialization
Operations	Operations, Monitoring, and Capacity
Report review	Visualization and UX · Accessibility and Multilingual Support

12. AI Contribution#

Use case	Benefit	Risk	Maturity	Prerequisites	Safeguards
Customize the checklist for a project (F/P/E items)	4/5	2/5	4/5	Project description	Review; keep security-related items
Pre-fill model review based on a TMDL diff	4/5	3/5	3/5	Diff export	AI proposes, reviewer decides; automatic checks take priority
Generate test scenarios (data edge cases)	4/5	2/5	4/5	Table schema	Actually execute; do not confuse scenario with proof
Draft release notes and communications	4/5	2/5	4/5	Change list	Business review
Draft the architecture decision record	3/5	3/5	3/5	Scorecard notes, verified numbers	No unverified pricing or limits

Typical prompt: “Here is the attached TMDL diff and the model review checklist. For each line, respond OK / To fix / Undetermined, with the diff line that proves it, and list the points that only a human can judge.”

🤖 AI

AI does not replace evidence (a checked box without query results is worthless), release accountability, or business validation. Main risk: a “green” review written confidently based on a diff it did not fully read. See 04 — AI (OneLake) and 08 — AI (SQL Server).

13. See Also#

In this section: Portal · 09 — comparison · 10 — cross-cutting good practices · 03 — OneLake pitfalls · 07 — SQL Server pitfalls
Methods: Scrum and data · Project Management Pitfalls and Best Practices (Cross-Cutting Summary) · CI/CD for Data: Databases, Datamarts, Pipelines, and Reports
Tools: Azure DevOps Server (Formerly TFS) In Depth · Version Control for Data: SQL and Power BI · Project Metrics and Reporting
Matrices: BI Development · Data Project Management · Self-Assessment with Maturity Matrices
References: GLOSSARY · RATING

✻ Written by Claude Sonnet 5.5