Why nobody opens your Power BI reports

A company spends nine months building a reporting layer. Usage reports show forty opens in the first week and six a month later. The conclusion that gets drawn is that people need training, so training happens, and usage goes to nine for a fortnight and then back to six.

Adoption is a symptom. In our experience it has five causes, and only one of them is about the people looking at the report.

1. The numbers do not match the ones people already trust#

Every business has a shadow number. It lives in a spreadsheet, it is maintained by someone in finance or ops, and it has been right for three years. The moment your dashboard shows something different, your dashboard is wrong — regardless of which one is actually correct.

You cannot argue your way out of this and you should not try. The fix is boring: reconcile, publicly, before launch.

Take the shadow spreadsheet, take your model, and produce a line-by-line reconciliation of the gap. Usually it is two or three things — a different date boundary, an exclusion nobody documented, a currency conversion applied at a different point. Write them down. Then either change your model or change the spreadsheet, and say which you did and why.

We have never regretted the week this costs. It converts the person who maintains the shadow number from your loudest critic into your best advocate, because they now understand the model better than anybody.

2. There is no semantic layer, only reports#

This is the most common structural problem and the most expensive to leave alone.

The pattern goes like this. A request comes in for a report. Someone writes a query, builds a dataset, publishes a report. Another request comes in, slightly different. Rather than extend the first model, they write a second query. Eighteen months later there are sixty datasets, each with its own definition of revenue, and nobody can change anything because nobody knows what depends on what.

A semantic layer is a single governed model where each business concept is defined once. Customer is defined once. Active loan is defined once. Revenue is defined once, with the exclusions in the definition rather than in whichever report remembered them.

Concretely, in a Power BI context, that means:

• One shared dataset per business domain, not per report
• A proper star schema — conformed dimensions, fact tables at a defined grain
• Measures written in DAX on the model, never in the visual
• Date handled by a marked date table, with fiscal and calendar hierarchies in it
• Row-level security defined on the model, so access does not depend on which file someone opened

The tell that you do not have one: two reports show a different number for the same thing, and the answer to "which is right" is "it depends who built it".

3. It is too slow to think with#

There is a threshold, somewhere around three or four seconds of interaction latency, past which people stop exploring and start requesting. They will not tell you the report is slow. They will just ask you for a spreadsheet instead.

Most slowness in a Power BI model comes from a small number of causes:

• Wide, flat tables instead of a star schema, forcing the engine to scan columns it does not need
• High-cardinality columns kept for no reason — free-text notes, GUIDs, full timestamps down to the millisecond
• Calculated columns doing work that belongs in the source or in a measure
• Bi-directional relationships added to make one visual work, slowing every other visual permanently
• DirectQuery used where import would do, usually because of a freshness requirement nobody actually has

Split a datetime into a date and a time column and you will frequently halve a model's size, because you have taken a column with millions of distinct values and turned it into two with a few thousand. That kind of change costs an afternoon.

4. It answers a question nobody asked#

A surprising number of dashboards are built from a requirements document that lists fields rather than decisions. The result is technically complete and practically useless: forty visuals, no point of view.

The test we use before building anything is to ask what decision this page changes, and who makes it. If the answer is vague, the page is a data dump with styling.

A page that works usually has this shape:

1. One headline number, and its comparison to a target or a prior period
2. Two or three drivers of that number, ordered by contribution
3. A way to get to the row level for the thing you just noticed

That is it. Contribution analysis at the top, detail at the bottom, and nothing in between that does not serve the move from one to the other.

5. Nobody owns it after launch#

Reporting that is not maintained decays quickly. A field gets renamed upstream, a source system changes its date semantics, a new market gets added and does not appear in the filter. Each of these produces a small wrongness. Small wrongnesses compound into a general sense that the reporting cannot be trusted, which is nearly impossible to reverse.

The minimum viable ownership is:

• A named owner per dataset, not per report
• Automated tests on row counts, freshness and referential integrity, alerting to a channel someone reads
• A published change log, so when a number moves people can check whether a definition moved with it
• A quarterly review that deletes reports nobody has opened

That last one matters more than it sounds. A reporting estate of twelve well-used reports is far more trusted than one of ninety, of which twelve are used.

The order to fix them in#

If you are looking at a low-adoption reporting layer and wondering where to start:

Reconcile against the shadow number first. It is the cheapest and it buys you the political room to do the rest.

Then fix performance, because it is usually mechanical and the improvement is immediately felt.

Then consolidate to a semantic layer, which is the big one and the one that pays back over years.

Then, and only then, revisit page design. Redesigning pages on top of a model people do not trust is redecorating a house with a leak.

Training goes last, if at all. If the model is right, fast and trusted, adoption tends to look after itself.