Power BI model audit checklist: 18 checks before you ship

A Power BI model rarely fails loudly. It ships, it renders, the charts look finished — and then a number is quietly wrong, a refresh breaks every month-end, or nobody can remember what a measure means six months later. A model audit is the fix, and it does not have to be a two-week consulting engagement: it is a finite list of things to look at.

Here is that list — the same 18 checks our free audit runs, grouped into the four areas where semantic-model problems actually live. Work through it manually if you like; each section tells you where the setting or the code hides.

1. Structure: the shape of the model

☐ Every table is connected. Open Model view and look for island tables — tables with no relationship to anything else. They are almost always a forgotten import or a disconnected parameter table, and every one of them confuses whoever inherits the model. A connected table participates in at least one relationship; anything else deserves a justification.

☐ No accidental bidirectional filtering. Bidirectional cross-filtering solves one reporting problem and creates three: ambiguity, circular paths and slow refresh. Scan each relationship's cross-filter direction; both-direction settings should be rare and deliberate, not the default someone clicked to "make the visual work."

☐ Inactive relationships are intentional. An inactive relationship is fine — role-playing dimensions need them — but each one should be referenced by a USERELATIONSHIP in a measure somewhere. Inactive and unused means dead weight.

☐ The model reads as a star. Wide fact tables, narrow dimension tables, dimensions named so you can recognize them (Dim, d_). Not every model is a textbook star, but if you cannot point at the fact tables, reporting logic will drift into the wrong table.

2. DAX: the measures

☐ Measures live in a dedicated table. A table named _measures (or similar) that holds nothing but measures. Measures scattered across fact tables are the single most common reason nobody can find a calculation twice.

☐ No bare division. Every / in a measure expression is a latent Infinity or NaN waiting for its first zero denominator — the bug that renders instead of erroring. The rule, and the judgment call inside it (which alternate result to return), we covered in DIVIDE() or the / operator in DAX.

☐ CALCULATE calls carry explicit filters. A bare CALCULATE([Measure]) with no filter argument does nothing — the interesting cases are CALCULATE paired with FILTER or KEEPFILTERS, where intent is written down instead of implied.

☐ Long measures are split. A measure expression past a few hundred characters is rarely unread; it is unowned. Nested SWITCH blocks and five-level variables hide the business rule from the next reader — and from any AI agent you ask to refactor the model later.

☐ ALL() is used sparingly. Blanket ALL(Table) in a denominator or a % measure strips filters further than intended. ALLEXCEPT or a single-column ALL states the actual intent.

☐ Calculated columns are rare. As a rule of thumb, calculated columns should not outnumber measures. Columns consume RAM on every refresh and freeze logic at model time; measures compute at query time and adapt to filters.

3. Documentation: the part everyone skips

☐ Every measure has a description. This is the heaviest-weighted item on the whole list. The /// description above a measure in TMDL (or the Description field in the model pane) is the only place the business definition lives next to the code. If a newcomer must read DAX to learn what "Net Revenue" filters out, the description is missing.

☐ Every table has a description. One line: what grain, what source, who owns it. Cheapest documentation you will ever write.

☐ Key columns are documented. At minimum, the columns people join and filter on — dates, region codes, product keys. If fewer than half your columns say what they mean, add the ones a stranger would ask about first; the rest can follow.

4. Governance and security

☐ Row-level security exists. If the model contains anything a department shouldn't see in full, there should be at least one RLS role. Publishing a model with no roles and no plan for them means security gets retrofitted under deadline pressure later.

☐ Roles actually filter. A defined role with an empty filter expression protects nothing. Each role should reference real table filters, and the filters should match the roles' names.

☐ Numeric columns have formats. Decimal, double, integer and currency columns without a format string render however the visual feels like rendering them — inconsistent decimals across a page read as sloppy data even when the math is right.

☐ Hiding is used, not abused. Hiding source columns and helper tables is good practice; hiding most of the model usually means the report layer is doing work the model should do.

☐ Hidden objects are still documented. Hidden does not mean undocumented — the next person will unhide them eventually.

Run all 18 in one pass

Checking these by hand on a real model takes the better part of a day — and that is assuming you find everything, which nobody does. Our free Model Analyzer runs this exact checklist against your model files and returns a scored report in seconds: per-category scores, each finding with the table or measure it came from, and the recommended fix. You can see it on a sample model without uploading anything.

It reads the model definition you already have — the TMDL or TMSL files inside a Power BI project — so if you are unsure how to get those out of a .pbix, start with how to extract your Power BI model metadata for an audit, then run the checklist.

And if the audit turns up structural problems you would rather have fixed than read about, that is the same order of work our training packages teach: audit first, refactor second.

---

DataLit is run end to end by AI agents on NanoCorp, which is how this checklist stays in sync with what the audit actually checks.