Power BI Dashboard Development
Dashboards people actually open. I build the data model underneath, the DAX that makes the numbers right, and the report layout that gets someone to an answer in two clicks.
Most disappointing Power BI projects fail in the same place, and it is not the charts. It is the model underneath — a flat table dragged in from Excel, calculated columns doing what measures should, and a refresh nobody scheduled. The visuals are the last five per cent of the work and the only part anyone photographs.
What you get
- A proper star schema, not a flat exportFacts and dimensions modelled correctly, with relationships that make totals add up at every level. This is what decides whether the report is fast and whether the numbers survive a drill-down.
- DAX that is measures, not calculated columnsMeasures evaluate in the filter context of whatever the user clicked. Calculated columns bloat the model and freeze at refresh time — which is why the same figure ends up disagreeing with itself in two visuals.
- Layout built around a questionHeadline number first, breakdown second, detail on drill-through. Not twenty visuals competing for the same screen because every stakeholder wanted one.
- Row-level security where it is neededEach regional manager opens the same report and sees only their own region. One report to maintain instead of nine copies drifting apart.
- Refresh that runs without youScheduled refresh in the Power BI Service, an on-premises gateway if the data lives behind your firewall, and failure alerts — so a stale dashboard announces itself instead of quietly misinforming a meeting.
An example of what you get
A search-performance dashboard of the kind I build, using a Google Search Console dataset.
Sample data. The figures below are representative of a real engagement, not a specific client's results. Any dashboard I build for you is populated from your own data.
Top queries — the same data as a table
| Query | Impressions | Clicks | CTR | Position |
|---|---|---|---|---|
| n8n vs make vs zapier pricing at volume | 4,820 | 611 | 12.7% | 3.1 |
| how much does an ai chatbot cost per month | 3,960 | 402 | 10.2% | 4.4 |
| power bi report slow how to fix | 2,140 | 268 | 12.5% | 3.8 |
| webhook vs api for crm integration | 1,780 | 194 | 10.9% | 5.2 |
| data cleaning | 9,640 | 61 | 0.6% | 24.7 |
| power bi | 12,400 | 38 | 0.3% | 41.2 |
The reading: short-tail terms supply 68% of impressions but only 21% of clicks, at well under 1% CTR — high-volume terms where the site ranks on page three and nobody clicks. Long-tail supplies 8% of impressions and 40% of clicks. A dashboard that reported impressions alone would say the short-tail terms were the win. They are the opposite.
My Power BI Dashboard Development process
Agree the questions and the grain
Which decisions the report serves, and the lowest level the data must go to. Getting the grain wrong is the one mistake that forces a rebuild rather than an edit.
Model the data
Power Query for shaping, a star schema with a proper date table, relationships and cardinality set deliberately rather than by auto-detect.
Write the measures
DAX for the KPIs, time intelligence, and the comparisons — with each measure checked against a number you already trust.
Build and tune the report
Layout, drill-through, bookmarks and slicers, then Performance Analyzer on every visual so nothing takes seconds to paint.
Publish, secure and schedule
Workspace and app setup, row-level security roles tested with real accounts, scheduled refresh, and a walkthrough so your team can use it without me.
Tools I use for this
Chosen per project against your constraints and budget — never one stack forced onto every problem.
Questions I get asked about this
Power BI, Tableau or Looker Studio — which should I actually use?
Mostly it follows what your business already runs on. If you are a Microsoft organisation — Microsoft 365, Azure, SQL Server, Excel everywhere — Power BI is the obvious answer: licensing is cheap per user, it authenticates against the accounts you already have, and it handles far larger models than the alternatives. Tableau is stronger for open-ended visual exploration by analysts and costs meaningfully more. Looker Studio is free and genuinely fine for straightforward reporting on Google data, but it strains on large models and complex logic. I will say when your case is a Looker Studio one, because recommending the expensive tool for a report that refreshes a Google Sheet once a day would be indefensible.
What licence do I need, and what does it cost each month?
Building is free — Power BI Desktop costs nothing. The cost starts when you share. Power BI Pro is a modest per-user monthly fee and each person who views the report needs one; for a team of five to fifty that is usually the whole bill. Premium Per User costs several times more and buys larger models, more frequent refreshes and paginated reports. Fabric capacity is billed per capacity rather than per person and only starts making sense at a few hundred viewers, or when you need to share with people outside your tenant without licensing each of them. Almost every small business is correctly served by Pro, and I will tell you before we start which of the three you are in rather than after you have built for the wrong one.
Can it connect to the systems we already use?
Power BI has native connectors for SQL Server, PostgreSQL, MySQL, Excel, SharePoint, Dynamics, Salesforce, Google Analytics, Google Sheets and a long list beyond. Anything with a REST API can be pulled through Power Query, and where a connector is genuinely missing I build a small pipeline that lands the data somewhere Power BI reads happily. The case that catches people out is data behind your own firewall — an on-premises SQL Server or a file share. That works, but it needs an on-premises data gateway installed on a machine that stays on, and that is an infrastructure decision worth making early rather than discovering at publish time.
Why is our existing Power BI report so slow?
Nearly always the model rather than the visuals. The usual causes, in the order I find them: one wide flat table instead of a star schema, so every filter scans everything; calculated columns doing work that belongs in measures, inflating the file and recomputing at refresh; bi-directional relationships switched on to fix a totals problem, creating ambiguity everywhere else; a date table missing, so time intelligence falls back to something expensive; and columns imported that nobody uses, each one costing memory. I run Performance Analyzer and DAX Studio to find which visual and which query is actually costing the seconds, because the slow visual is often not the broken one. A model rebuild usually takes less time than people fear and is frequently the only thing that helps.
Can different people see different data in the same report?
Yes — that is row-level security, and it is the right answer to what people usually solve by emailing nine filtered copies of a workbook. You define roles with a filter rule, map them to your organisation's accounts or security groups, and each viewer opening the same report sees only their slice. One report to maintain, one version of the truth, and no filtered copy quietly going stale in somebody's inbox. It has to be tested with real accounts rather than the preview button, because the preview does not exercise group membership, and I do that as part of publishing.
Get a dashboard your team will actually open
Tell me the question you keep rebuilding a spreadsheet to answer. That is usually the whole brief.
Start with a free discovery call