Without a governed semantic layer, Power BI reports become inconsistent and unmaintainable. Here's why it matters and how to fix it.
Most Power BI implementations follow the same pattern. A consultant or internal developer connects directly to a data source, builds a report, and publishes it. Six months later, there are fifteen reports, each connected differently, each calculating the same metrics slightly differently, and nobody quite trusts any of them.
This connects with our Power BI service and, separately, with The Business Central reports a finance team needs.
What a semantic model actually is
A semantic model (previously called a Power BI dataset) is a reusable, shared data layer that sits between your raw data sources and your reports.
- The data model: tables, relationships, and schema normalisation
- Business logic: DAX measures that define your key metrics once, consistently
- Row-level security: access controls applied at the model layer, inherited by all connected reports
- Documentation: metric definitions, table descriptions, and data lineage
- Certification: an endorsement that tells users this is the authorised source
Why implementations skip it
Speed pressure
Building a report directly from a data source is faster than designing and building a proper semantic model first. When there's pressure to deliver quickly, the semantic layer looks like unnecessary overhead.
Underestimation of scale
The first report feels simple. When the brief is 'a dashboard for the finance team', it's hard to anticipate that it will become ten dashboards used by the whole business. The architecture decisions made for the first report get inherited by the tenth.
The cost of skipping the semantic layer isn't visible at the start. It's visible at report fifteen, when changing one metric definition means editing fourteen reports individually, and you can't be sure you've caught them all.
Designing a semantic model correctly
A well-designed semantic model is built around the business, not around the source system. The starting point is a conversation: what decisions does this data need to support? What are the key metrics, and how does the business define them?
From there, the model earns its certification in stages. Start with the metrics that cause the most argument in the business, such as revenue, margin and headcount, and get those agreed and built first. Publish the model, certify it, and route new report requests through it rather than back to the raw source. A report that still needs something the model does not provide is a signal to extend the model, not a reason to build around it.
Ownership matters as much as design. Somebody needs to own the semantic model the way a product owner owns a product, reviewing change requests, deciding what gets added, and saying no to the metric that only one team needs and nobody else agrees with. Without a named owner, the model drifts back into the same mess it was built to fix.
The pattern that works best is incremental: one well-governed model, covering the metrics that matter most, growing report by report, rather than a big-bang rebuild of every report on day one. That is the same principle behind how we approach phased delivery, and it applies just as much to a semantic model as it does to a platform rollout.
If any of this sounds familiar, talk to us about your data.
Related reading
- Why Power BI Reports Show Different Numbers - and How to Fix It
- Consolidating multiple Business Central companies in one model
- Why Your Self-Service BI Rollout Collapsed
Simon Devine
Managing Director
Part of the Hopton Analytics team, delivering governed analytics programmes for UK mid-market organisations.