What it is
A row count anomaly occurs when the number of rows loaded into a semantic model table after a refresh deviates significantly from its expected value. This can be a sudden drop (missing data), a spike (duplicate data), or a complete absence (zero rows).
Row counts are one of the simplest and most reliable signals of data health. A table that consistently has 1 million rows and suddenly loads 50,000 rows almost certainly has a data issue — even if the refresh succeeded.
Anomalies can be caused by source query changes, ETL failures upstream, permission revocations on source tables, filter changes in Power Query, or source data actually changing (legitimate business events vs. errors).
Why it matters for Power BI teams
- Row count drops often mean reports are showing incomplete data, leading to incorrect business decisions.
- Zero-row loads are invisible to the refresh engine — the refresh succeeds, but the data is empty.
- Row count spikes may indicate duplicate data loading, inflating metrics and totals.
- Without baseline comparison, there is no way to know whether a row count is "normal" or anomalous.
- Early detection of row count issues prevents compounding problems in downstream reports and datasets.
Why Power BI doesn't catch it well
Power BI does not track row counts between refreshes. There is no built-in mechanism to compare the current row count with the previous one.
The refresh engine validates the technical success of the load, not the correctness or completeness of the data. A table loading zero rows is not flagged.
Row count information is available through DMVs or XMLA endpoints, but Power BI does not surface it in the portal or use it for monitoring.
How teams detect it today
- Running DAX queries (COUNTROWS) against published models via XMLA endpoints — requires PPU or higher.
- Building validation reports that display row counts and comparing them manually after each refresh.
- Checking source databases for expected row counts and comparing post-refresh.
- Relying on end users to notice when totals or aggregates look wrong.
- Using Power Automate or custom scripts to query and log row counts periodically.
How SummitView helps
- SummitView captures row counts per table after each refresh and compares them against historical baselines.
- Configurable anomaly thresholds let teams set acceptable deviation ranges (e.g., flag changes greater than 20%).
- Zero-row loads are flagged immediately as critical anomalies.
- Historical row count trends help distinguish between legitimate data growth and unexpected changes.
- Alerts for row count anomalies are independent of refresh status — a "successful" refresh with wrong data is still caught.