Power BI dashboards that lie: when your lookup tables go stale
A VP opens the executive dashboard. The total revenue is fine. The breakdown by region is fine. The breakdown by product family is wrong, but only if you know to look. There is a category called "other" that did not exist last month, accounting for fourteen percent of the total.
The VP does not notice. The CFO does not notice. The board pack goes out with the wrong product mix on page nine.
A week later somebody on the data team traces it back. A new product was launched twenty days ago. The warehouse picked it up. Power BI joins the product to a lookup table in a SharePoint folder, last updated three months ago. The new product is not in it. Power BI's default behaviour when a join misses is to bucket the row into "other".
The dashboard lied without anyone noticing.
Why these failures are silent
The dashboard does not break. It becomes wrong in a way that nothing on the screen flags. No error indicator, no banner. The visuals render normally. The only way to catch it is to know that "other" should be small, or that "unmapped" was zero last month and should still be zero this month.
The lookups that go stale routinely
| Lookup type | Common cause |
|---|---|
| Product mappings | New product, lookup not updated |
| Customer segmentations | CRM reclassifies, warehouse lags |
| Cost centre hierarchies | Org restructure not propagated |
| Geography | New states or regions silently dropped |
| Status values | Source adds a new status |
| Currency rates | Manual update missed |
| Tax rates | Statutory change not entered |
Same anti-pattern in each case: the lookup is maintained outside the source system, manually.
The product-mapping case is the classic. Marketing launches a new SKU on Monday. The warehouse ingests transactions on Tuesday. The dashboard refreshes Tuesday night. By Wednesday morning, the executive report shows the new sales as "other". By the time anyone looks at the breakdown carefully, the launch is two weeks old.
Four patterns that catch staleness
Unmapped count as a KPI. Every dashboard with a lookup shows the unmapped row count alongside the other metrics. When it goes above zero, the dashboard is telling you it is lying.
Alerts on new source values. The warehouse compares distinct source values against the lookup and alerts when a new source value appears unmapped. This catches the lie before the dashboard renders it. In gridmap, delta sync on a registry detects new values on a schedule and notifies the named owner before the next report runs.
Lookup ownership. Every lookup has a named owner. New values trigger a notification to them, not to the data team that happens to be on call.
Centralised lookups. Each dashboard does not own its own CSV. The lookups live in a central registry; updates propagate everywhere. The maintenance burden is paid once.
A short audit checklist
- Find every dashboard with a lookup join. List them.
- For each, find where the lookup actually lives.
- For each lookup, find the owner. No owner means the lookup is already stale.
- For each, check the last modified date against the source system's last new value.
The first time you do this, you will find at least one dashboard you should not trust.
FAQ
Why does Power BI default to bucketing into "other"? Because failing the visual was less user-friendly during design. Reasonable for charts. Wrong for production dashboards. Override the default where it matters.
Should the lookup live in the warehouse or in the BI tool? The warehouse. BI tools change every few years; the warehouse usually outlives them.
What about Tableau? Same problem, different defaults. Audit the same way.
If your team is still maintaining lookup CSVs in SharePoint folders for production dashboards, you are running on luck. Luck does not last.