What we keep finding inside Power BI files

Over twelve years of auditing Power BI environments inside tier-one metals and mining operators, a pattern emerges. The problems are rarely exotic. The same issues appear in file after file, built by different teams, on different continents, for different programs. When we productised that audit into Nexlytics, we were not inventing a checklist. We were encoding what we had already seen hundreds of times.

Here is what we actually keep finding.

The findings

Unused tables and columns that nobody removed

A model gets built to answer a specific question. Six months later the question changes, a new table comes in, and the old one stays because nobody is sure if something still depends on it. Repeat that cycle a few times and you end up with a .pbix that imports four times the data it actually uses. We have opened files where more than half the columns in the model were unreferenced by any measure or visual. The file is slow to refresh, slow to open, slow to publish, and the next person who inherits it has no way to know what is live and what is dead weight. The performance hit is real and the cognitive tax on the next builder is worse.

Duplicate measures that drifted and now disagree

This one is the most common source of stakeholder credibility damage. A measure gets created, works well, gets copied into a second table or report page for convenience, and the two copies are edited independently over time. By the time someone notices, the revenue figure on slide 3 of the executive report does not match the revenue figure in the operational dashboard. Both are sourcing from the same underlying data. The divergence is in the measure logic itself.

We have seen this in environments with fifteen copies of what started as a single rolling-twelve-months calculation, each one slightly different. The team had lost track of which was the canonical version. The answer to "which number is right" required a model audit, not a data investigation.

Row-level security that is missing or misconfigured

RLS is frequently bolted on after the fact, or configured for the original scope and never updated when the report gets shared more broadly. The most common failure mode is a role that exists in the model but is not enforced in the published workspace, meaning every viewer sees every row regardless of what the RLS rules say. The second most common is a role that is enforced but written against a column that gets renamed in a subsequent data source update, silently breaking the filter and showing blank data rather than restricted data.

In a corporate environment with business unit or site-level access controls, a misconfigured RLS is a compliance problem, not just a data quality problem.

Calculations that silently double-count

DAX is unforgiving when the relationship model is not what the author assumed. A many-to-many relationship handled with a bridge table, where the bridge was set up correctly but a second measure was written against the fact table directly, will double-count in specific filter contexts and produce correct results in others. The error is not obvious because the numbers are plausible. They are wrong only when you compare them against a source system total that someone thought to check.

We regularly find CALCULATE blocks with filter arguments that interact with bidirectional relationships in ways the author did not anticipate. The measure passes the eyeball test on the report page and fails the reconciliation against the ERP.

Refresh dependencies that break without warning

Scheduled refreshes fail silently or with error messages that do not identify the root cause clearly. The underlying problem is usually a parameter-driven data source where the parameter was set up on one machine and the gateway does not have the corresponding credential, a SharePoint path that changed when a team moved folders, or a SQL query that references a view that was dropped in a database migration. None of these are difficult to fix once found. They are difficult to find because the failure notification goes to whoever set up the scheduled refresh, which is often not the person who owns the report day-to-day.

No documentation, and the builder has left

This is the problem that makes all the others worse. When a model is well-documented, a new owner can reason about what is intentional and what is technical debt. When there is no documentation, every assumption is invisible. We regularly audit files where the measure names are abbreviations that made sense to one person, the data source is a local extract with no provenance trail, and the only person who knew what the transformation logic was trying to do left the organisation eighteen months ago.

The cost of undocumented models compounds over time. The first inheritor makes conservative changes. The second inheritor stops changing it at all. Eventually the report gets rebuilt from scratch because nobody trusts the original, and the cycle restarts.

The report matches but the export does not

This one surprises people. A visual on a report page applies visual-level filters that do not carry into the exported data. A measure that uses ALLSELECTED behaves differently in an Export to Excel versus the rendered visual. A table with conditional formatting that hides rows visually exports all rows. The report page and the spreadsheet a manager sends to their director contain different numbers from the same file, and the manager does not know it until someone asks.

Why these patterns repeat

None of these are failures of intelligence or care. They are failures of tooling and process. Power BI was designed to make it fast to build reports. It was not designed to make it obvious when a model has accumulated technical debt, or to surface configuration gaps before they become problems. The people who build these models are skilled. They are working under time pressure, inheriting files from predecessors, and operating without audit tooling that would catch these issues automatically.

The reason Nexlytics exists is that for twelve years we ran this audit manually. It took days. We built the tool to run it in ninety seconds.

See what is in your .pbix for $9