What it is
A "successful" refresh in Power BI means the data load process completed without a technical error. It does not mean the data is correct. A refresh can succeed while loading zero rows, duplicate records, stale source data, or data from the wrong environment.
This is one of the most dangerous scenarios in Power BI administration because every signal says "everything is fine." The refresh status is green. No alerts fire. But the numbers in reports are wrong.
Causes include source queries returning empty results due to permission changes, ETL jobs that have not completed before the refresh runs, data sources pointing to staging instead of production, and partial loads due to query timeouts that are handled gracefully.
Why it matters for Power BI teams
- Business decisions are made on data that appears current but is actually incorrect.
- There is no technical failure to investigate — admins have no reason to look unless someone reports it.
- Detection often takes days because the error is in the data content, not the refresh process.
- Trust in the BI platform erodes when users discover numbers were wrong after acting on them.
- Root cause analysis is difficult because the refresh metadata shows no anomaly.
Why Power BI doesn't catch it well
Power BI's refresh engine validates that the load process completed, not that the loaded data is correct or complete. A refresh that loads zero rows into a table is still recorded as "Completed."
There is no built-in row count comparison, data validation, or anomaly detection in the refresh pipeline.
Power BI does not compare current data with previous refresh data. It has no concept of "expected" data characteristics.
How teams detect it today
- End users report wrong numbers in reports — the most common and slowest detection method.
- Manually spot-checking key metrics after each refresh window.
- Building validation queries in the source database and comparing post-refresh.
- Using DAX queries against the published model to check row counts (requires XMLA access).
- Creating separate validation reports that compare current data against known benchmarks.
How SummitView helps
- SummitView tracks row counts per table after each refresh and flags unexpected changes (drops, spikes, or zero-row loads).
- Anomaly detection compares current row counts against historical patterns to identify silent data issues.
- Schema change detection catches when columns are added, removed, or renamed — a common cause of wrong data.
- Alerts fire on data quality signals independently of refresh status, so "successful but wrong" refreshes are caught.
- Historical row count trends help identify when a data quality issue first appeared.