Anyone can build the dashboard. The model underneath is the job.
Power BI reports fail for the same reasons almost every time: a model shaped like a spreadsheet, DAX that works on ten thousand rows and dies on ten million, and a refresh nobody notices has stopped.
Six reasons a Power BI deployment stops being trusted.
Almost every rescue engagement we take on has at least four of these. They are all model problems presenting as report problems, which is why replacing the report never fixes them.
- One flat table instead of a star schema. Built by importing a spreadsheet or a wide extract. It works until filters interact, at which point totals stop reconciling and nobody can explain why.
- DAX written like Excel formulas. Row-by-row logic that the storage engine cannot optimise. Fast on sample data, unusable at production volume, and the fix is usually a rewrite.
- Bidirectional relationships used to make something work. The most common source of ambiguous filter paths and wrong numbers that look plausible; the worst kind of wrong.
- Row-level security bolted on afterwards. Added once someone asks the compliance question, at which point it interacts badly with a model never designed for it.
- Refresh failing silently. The report still opens and still shows numbers. They are just from Tuesday, and someone is presenting them on Friday.
- Every question answered with a new report. Forty reports, no model. A symptom of a semantic layer that was never built, and the reason the BI team is permanently behind.
What we ask a Power BI consultant.
The screen is mostly modelling. Visual design is teachable in a fortnight; a correct model is not.
Walk us through your last star schema.
Facts, dimensions, grain, why the grain was chosen. A candidate who cannot articulate grain has been building flat tables.
When would you use a bidirectional relationship?
The right answer is close to never, with a specific exception. Anyone reaching for it as a normal tool will produce ambiguous filter paths.
How do you make a slow measure fast?
We want storage-engine versus formula-engine reasoning and a mention of DAX Studio or the performance analyser, not a guess about visuals.
How have you implemented row-level security?
Dynamic RLS against a user table is the answer that shows real deployment experience, along with an account of how it was tested.
How do you know a refresh failed?
Alerting, gateway monitoring, ownership. Silence here means their reports have been stale and nobody found out from them.
How do you handle a definition disagreement?
The hardest part of BI is not technical. We are listening for someone who drives the business to a single definition, not shipping both.
What a Power BI engagement usually also touches.
Almost nobody hires for Power BI alone. These are the adjacent pieces our consultants work in, and it is worth being explicit about which ones you need.
| Area | What it covers | How often it comes up |
|---|---|---|
| Semantic modelling | Star schemas, grain, relationships, calculation groups | Every engagement |
| DAX | Measures, time intelligence, performance tuning | Every engagement |
| Power Query / M | Ingestion, shaping, incremental refresh | Most |
| Source modelling | Views and warehouse structures upstream of the model | Most, often the real fix |
| Deployment | Workspaces, pipelines, gateways, capacity | Most |
| Security | Row-level and object-level, tested against real roles | Enterprise |
| Microsoft Fabric | Lakehouse, Direct Lake, where it genuinely helps | Growing |
| Power Automate / Apps | Write-back and workflow around the reporting | Occasionally |
Rates, notice and how we interview, on one page.
The commercial mechanics are the same whichever role you are hiring, so they live in one place, not being restated on every page.
Hiring Power BI people.
Including whether you need a consultant at all.
Our team already uses Power BI. What would a consultant add?
Usually the semantic layer. Self-service Power BI adoption tends to follow the same trajectory: enthusiastic early progress, a proliferation of reports, and then a slow loss of trust as numbers stop agreeing between them. That is not a skills failure by your team, it is the predictable result of building reports without a shared model underneath. A consultant's value is building that model, migrating the reports that matter onto it, and leaving your team able to extend it. If your reports do reconcile and refresh reliably, you may not need us, and we will say so, not finding something to sell.
Should we move to Microsoft Fabric?
It depends on whether you have a data platform problem or a reporting problem, and most organisations asking this have the second. Fabric is useful where you are consolidating a warehouse, a lake and reporting under one commercial and operational umbrella, and Direct Lake removes real import-refresh pain at large volumes. It does nothing for a badly modelled dataset, a flat table on a lakehouse is still a flat table. Our advice is almost always to fix the model first, on whatever you are running today, and evaluate Fabric as a platform decision on its own merits afterwards.
Can one person do both the modelling and the visual design?
Usually yes, and it is often the better arrangement, because the person who understands the grain of the model designs visuals that cannot be misread. The place it breaks down is at the top end of visual design, a well-designed executive report is a design discipline, and modelling specialists are frequently only average at it. For most internal reporting that is a perfectly acceptable trade. Where the output is going to a board or to customers, we would put a designer alongside for a short period rather than expecting one person to be excellent at both.