Model flags
Ten checks on the semantic model: what nothing uses, what exists twice, what is calculated, and what Power BI created on your behalf.
Unused tables, columns and measures
severitywarningcategorymodelHealth ScoreUnused
Nothing in the report refers to the object — no visual, no filter, no other measure.
Why it matters. Unused objects are the largest single influence on your Health Score, and they are usually the easiest thing to fix. They also make the model harder for the next person to read: every column in the field list is a column someone has to decide about.
What to do. Remove it once you have confirmed it is really unused.
Check other reports first
"Unused" means unused by this report. If the semantic model is shared, a column no page here touches may be central to another report. Row-level security rules can also use a column without any page showing it.
Treat these as candidates to review.
Tables get two exemptions, so they will not appear here if either applies: a table used in any relationship, and a table read by a DAX formula (which gets its own flag, below).
Duplicate tables
severitywarningcategorymodelHealth ScoreStructural
Two tables hold the same set of columns — same names, same data types, same source columns.
Why it matters. Usually a copy someone made and forgot, which then gets refreshed and stored forever alongside the original.
What to do. Keep one and point everything at it.
Small tables are left alone: a table needs at least three columns before an identical structure counts, so two little lookup tables that happen to match are not reported.
Duplicate columns
severitywarningcategorymodelHealth ScoreStructural
The same column appears in more than one table — same name, same data type, same source column.
Why it matters. Two copies of the same data drift apart, and it stops being obvious which one a visual should use.
What to do. Consider removing the copy and using a relationship.
Join keys are never reported. The same key on both sides of a relationship is how the model is supposed to work.
Duplicate measures
severitywarningcategorymodelHealth ScoreStructural
The same measure name is defined more than once.
Why it matters. This is the one worth chasing. Two measures called Total Revenue on different tables is how one report ends up showing two different answers to the same question, and how people stop trusting it.
What to do. Keep one definition.
Calculated column
severityinfocategorymodelHealth Scorenot scored
The column is written as a DAX formula and stored in the model, instead of coming from the data source.
Why it matters. Having calculated columns is not a fault, which is why this is information and not a warning. But each one is computed for every row and stored in the model, so it costs refresh time and file size.
A long list here is worth a look: it often means work that belongs upstream, in the source query or in a measure, has drifted into the model.
What to do. Where a calculated column is heavy or duplicated across tables, consider moving the logic to the source query or rewriting it as a measure.
Auto date tables
severitywarningcategoryperformanceHealth ScoreStructural
A hidden date table Power BI generated because Auto date/time is switched on.
Why it matters. Power BI creates one of these for every date column in the model, each with its own hierarchy. On a model with a dozen date columns that is a dozen invisible tables inflating the file and the refresh.
What to do. Switch off Auto date/time in Power BI Desktop and use one shared date table.
Usually the biggest single win
This is normally the largest Health Score improvement available from one change, and it makes the model smaller at the same time.
The finding names the table and column the date table was generated for, so you can see which of your columns caused it.
Automatic hidden tables
severityinfocategorymodelHealth ScoreMinor
A table Power BI generated and hid, or a system table.
Why it matters. Mostly it does not — this is information, not a problem, and these are rarely yours to remove. It is here so the object counts add up and so you can see how much of the model you did not write.
Tables used in DAX only
severityinfocategorymodelHealth ScoreMinor
The table is on no page, but a measure or calculated column reads from it.
Why it matters. This exists so the unused check does not lie to you. Without it, a lookup table that no visual touches but three measures depend on would be reported as unused, and deleting it would break those measures.
What to do. Keep it if the calculation needs it. If the measure that reads it is also flagged as unused, the whole chain can usually go.