For dashboards nobody has trusted since the second query broke
Power BI
Most Power BI failures never touch the visuals: a data model with no star schema, a DAX measure copied without understanding it, or a refresh that times out once real volume arrives. This practice treats the model underneath the dashboard as the actual deliverable, with security, performance and adoption owned through to the day people stop asking for the old spreadsheet.
How a Power BI data model gets designed here
Star schema, DAX validation and the rollout that decides whether it gets used.
90 secSample frame · video pending01Before a single table gets loaded
Import or DirectQuery is a real decision.
The connection mode gets picked by default far too often, and it decides your refresh strategy for the life of the report. Four questions settle it against your actual data.
How fresh does the data need to be?
Import mode refreshes on a schedule and suits daily or hourly needs well. DirectQuery queries the source live, which matters when the number must reflect this exact minute.
How large is the underlying dataset?
Import mode compresses and caches data for fast, responsive reports at most volumes. Very large datasets can outgrow that cache and push the decision toward DirectQuery instead.
What can the source system handle?
DirectQuery sends a query to the source on every interaction, which a fragile or heavily used source may not tolerate well. Import mode protects the source from that load entirely.
Does row-level security need to reach the source?
Import mode enforces row-level security inside the Power BI model itself. DirectQuery can also push that security down to the source system when the source demands it.
| Import | DirectQuery | |
|---|---|---|
| Data freshness | Scheduled refresh | Live at query time |
| Performance at scale | Fast, cached | Depends on source speed |
| Load on the source system | None after refresh | On every report interaction |
| Best fit | Most reporting needs | Near-real-time, source-governed data |
02Agreed before modelling starts
The ledger that keeps a Power BI build honest
Power BI engagements slip when the data model gets treated as an afterthought to the dashboard design. This ledger fixes what you bring, what we model and build, what returns to you, and what your team keeps control of throughout.
- Your side
You bring
- The spreadsheets and source systems your reports currently pull from
- The specific numbers leadership actually checks each month
- Any known inconsistencies between reports that currently disagree
- Our side
We build
- A star-schema data model built from your actual source systems
- DAX measures validated against numbers the business already trusts
- A refresh schedule that replaces the manual rebuild
- Your side
You receive
- A governed data model behind every dashboard
- Documented DAX measures with their business logic explained
- A live report that refreshes without anyone touching a spreadsheet
Never leaves you
- The decision on which numbers matter to the business
- Ownership of the source systems feeding the model
- Sign-off on every measure before it goes live
Where the line sitsWe build the model that makes the number trustworthy; you keep the decision on which number the business actually needs.
03From data model to a report people use
Four stages, each closing on a working report
Dashboards that nobody trusts usually skipped a stage here rather than a step inside one. This system closes each stage with something a business owner can actually verify.
Design the data model first
Fact and dimension tables get modelled into a proper star schema before any chart gets built. A dashboard on a broken model just makes the mess look presentable.
A schema before a single visualBuild and validate DAX together
Every measure gets checked against an answer the business already trusts, calculated by hand. A DAX formula that looks right and calculates wrong is worse than no report at all.
Measures reviewed against real business logicApply row-level security deliberately
Access rules get modelled around real reporting roles and tested with sample accounts before rollout. Nobody discovers a security gap by seeing a number they should never have seen.
Security scoped to who should see whatRoll out with training, not just a link
Dashboards ship with a walkthrough for the team that will use them daily. Usage gets tracked after launch, so adoption is evidence, not an assumption sitting in a slide.
Adoption measured, not assumed
04What actually moves the number
Four drivers, priced from the assessment
Power BI work is priced against the scoping assessment, because these four factors change effort well beyond what a per-dashboard estimate assumes.
Number and complexity of data sources
One clean database is simpler to model than five systems with different formats and no shared key between them.
Row-level security depth
A single shared view costs less than security scoped to dozens of roles, each seeing a carefully limited slice of the same data.
Data volume and refresh frequency
Small datasets refreshing daily are straightforward. Near-real-time reporting over large volumes demands more deliberate performance and architecture work.
Adoption and training scope
A dashboard for one analyst needs less rollout than one replacing a report a hundred people relied on every week.
05Evidence and proof
Dashboards people open without being reminded to.
Power BI proof is a report people actually check, not a demo that impressed a steering committee once. Every record here waits for written client approval before production.
Explore case studies
Board reports that stopped taking three days to rebuild every month.
Koru Health's leadership team waited on numbers manually rebuilt in spreadsheets before every board meeting. A star-schema data model and a scheduled refresh turned a three-day rebuild into a dashboard that updates itself.
- Monthly rebuild time
- 3 days to same-day
- Reports pulling from the same model
- 7
A security model that let five departments share one deployment safely.
Orra Systems needed several departments to share one Power BI workspace without seeing each other's numbers. Row-level security scoped to real reporting roles let five departments deploy from a single, tested model.
- Departments sharing one workspace
- 5
- Security gaps found in testing
- Caught and closed
People actually open this dashboard every morning, which never happened with the version we built ourselves.
Sample · pending client approval
06Read this first
When a new Power BI build is the wrong answer
Building a governed data model for a report three people will glance at once is more ceremony than the need justifies. The exits below are marked plainly.
A single Excel PivotTable already answers this
One-off, one-person analysis is often served better by a spreadsheet than a maintained Power BI report nobody else will reuse.
- Data practice
The underlying data model changes weekly
Building measures on a schema still being redesigned means rebuilding them again shortly after. Stabilise the data model first.
- Team extension
You need BI developers, not a delivery layer
If your team already owns the reporting roadmap and needs capacity, team extension fits better than a commissioned build.
| Shape | Best when | You direct | We carry |
|---|---|---|---|
| Scoped build | Reports and sources are known | Access decisions and priorities | Modelling and delivery |
| Delivery pod | Reporting needs will evolve | Product decisions each cycle | Engineering and dashboard design |
| Team extension | Your leads own the BI roadmap | Architecture and standards | Named developers and continuity |
07Straight answers
Asked before a Power BI budget is signed off.
01Do you build the data model or just the dashboard on top?
The model, always. A dashboard is only as trustworthy as the star schema and DAX measures underneath it, so the model gets built and validated before a single visual gets designed.
02Should we use Import mode or DirectQuery?
Whichever your data freshness and volume actually require, decided against those four questions. Most reporting needs are served well by Import mode, with DirectQuery reserved for near-real-time cases.
03Can you fix an existing Power BI deployment instead of rebuilding it?
Yes, and that is the more common request. Most engagements start by auditing the existing model, measures and security, then repairing what is broken rather than starting over.
04How do you handle row-level security across departments?
Security roles get modelled on real reporting responsibilities and tested with sample accounts before anyone else sees the report. Nobody finds a gap by seeing data they should not have.
05What does Power BI consulting cost?
Priced against source complexity, security depth and data volume, from the scoping assessment. A single-source dashboard costs far less than a secured, multi-department deployment.
06Can you connect Power BI to Dynamics 365 or SharePoint data?
Yes, that is one of the most common requests inside the Microsoft practice, and it gets scoped as part of the same engagement rather than treated as a separate project.
07How do you make sure people actually use the dashboard after launch?
Through a rollout stage that includes training and usage tracking, not just a shared link. Adoption gets measured after launch, so it is evidence rather than an assumption.
08Is this a staffing arrangement or a delivery engagement?
This is delivery work, not staffing. Our team designs the model, builds the measures and carries the rollout, so you evaluate a finished report instead of a stack of resumes.