Business intelligence

Power BI semantic models and reporting

Most Power BI estates do not have a tooling problem. They have forty reports, six versions of revenue and one person who knows which file is current. We rebuild the layer underneath: certified semantic models, security that follows identity, and a release process that is not a republish.

What we build

Certified semantic models. One model per subject area, holding the business logic once: the measures, the date table, the relationships and the naming the business recognizes. Report authors build on top of it instead of rebuilding it. Certification is not a badge here, it means the model has a named owner, a documented definition per measure and a release process.

Security that follows identity. Row-level security driven by Entra ID group membership, so a manager sees their own region because of who they are, not because a filter was remembered. Object-level security where the column itself is confidential. Both are tested with a documented set of cases, because security you have not tested from an end user’s account is an assumption.

Deployment pipelines. Development, test and production workspaces with a promotion path between them. Changes are reviewed before they reach the audience. The alternative, editing in production, is the single most common cause of a Monday morning where the numbers moved and nobody can say why.

Gateway and refresh reliability. A clustered on-premises data gateway rather than a single machine, credentials in a managed store, refresh schedules that match when the source data is actually ready, and failure alerts that reach a human. A refresh that fails silently is worse than a refresh that fails loudly.

Report design that survives contact with executives. A small number of reports, each answering a question someone actually asks, with consistent layout, accessible colour contrast and performance measured rather than assumed. We remove more visuals than we add.

Performance work that is measured. Model size, refresh duration and visual render time are recorded before and after. Where a report is slow, the cause is identified rather than guessed: usually a model with no date table, a calculated column doing a measure’s job, or a visual returning fifty thousand rows to a table nobody scrolls.

Tenant governance. Workspace structure, who may publish, external sharing rules, and an inventory of what exists with its owner and last use. Reports nobody has opened in a year are retired rather than maintained. Licensing is reviewed against actual usage at the same time, because Pro licenses assigned to people who left are a recurring and entirely avoidable cost.

A report page, and what has to sit underneath it A row of measures across the top, then a column chart, a trend and a table, with the filters on the right. Every figure and label below is a placeholder chosen to be obviously generic: this shows how a report page is laid out, not anybody’s results, and none of it is a measurement of ours.
Power BI report page Overview Four visuals and a filter pane, all reading one certified semantic model. The figure at the top left and the figure in the table cannot disagree, because there is only one definition of it.
  • Measure A 1 200 Current quarter
  • Measure B 860 Current quarter
  • Measure C 24 % Share of total
  • Measure D 310 Current quarter
Units by region Placeholder values, regions 1 to 6.
60 30 0
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
Units by quarter Placeholder values, two series over eight quarters.
60 30 0
  • Q1
  • Q2
  • Q3
  • Q4
  • Q5
  • Q6
  • Q7
  • Q8
  • Series 1, solid line
  • Series 2, dashed line
Units by region and segment Placeholder values.
Region Segment Units
1A420
2A310
3B260
4B180

Filters

  • Region Selected: all
    • Region 1
    • Region 2
    • Region 3
  • Quarter Selected: Q3
    • Q1
    • Q2
    • Q3
    • Q4
  • Segment Selected: A and B
    • Segment A
    • Segment B

What makes the page above trustworthy

  • Model Certified semantic model One model per subject area, with a named owner and a documented definition per measure. Report authors build on it instead of rebuilding it, which is what stops the fortieth report inventing a forty-first definition.
  • Security Row-level security Driven by Microsoft Entra ID group membership, so a manager sees their own region because of who they are and not because a filter was remembered. Object-level security where the column itself is confidential.
  • Release Deployment pipelines Development, test and production with a promotion path between them. Editing in production is the single most common cause of a Monday where the numbers moved and nobody can say why.
  • Direct Lake Where the model reads Where a lakehouse sits behind the estate, the model reads its tables directly, which removes the import refresh window and the second copy of the data that came with it.
  • Placeholder figures and generic labels throughout. Nothing here is a measurement, a client result or a number of ours: a plausible fake indicator would be worse than an obviously neutral one, because only the first gets quoted back.
  • A drawing of a report page in our own typography. No logo and no product interface: an imitation that nearly matches mostly says that you do not have the thing.
  • The two lines are told apart by their stroke as much as by their colour, one solid and one dashed, because the two colours have almost the same lightness and colour alone is never the only signal.
  • The filter pane lists the choices and says in words which one is selected; it is not a working form. A control that looks interactive and does nothing takes keyboard focus and answers nothing.

The forty-report problem

The usual starting point is an estate that grew one urgent request at a time. Each report carries its own copy of the logic, each was correct on the day it was built, and together they now produce three answers to the same question. The instinct is to audit all forty. That takes a quarter and changes nothing.

We work the other way. We identify the four or five subject areas that carry real decisions, build a certified model for each, rebuild only the reports that are genuinely in use on top of them, and retire the rest with their owners’ agreement. The end state is smaller than the starting point, which is the point.

How the engagement runs

Weeks 1 and 2, inventory and definitions. What exists, who uses it, what each measure is supposed to mean, and where the definitions conflict. Output is a written definition set signed off by the business, not by us. This is the hardest fortnight and it is not a technical one.

Weeks 3 and 4, the first certified model. Built on the highest-value subject area, with row-level security, documentation and one production report. Your report authors build the second report themselves, with us in the room.

Week 5, platform and release process. Workspace structure, deployment pipelines, gateway rebuild, refresh alerting, licensing model and the tenant settings that govern sharing.

Week 6, second model and handover. The second subject area is built largely by your team. We document, run a build session with the report authors, and leave a prioritized list of what remains.

What you keep

  • Certified semantic models with a named owner and a documented definition per measure.
  • The written business definition set, in your own words, agreed across departments.
  • Row-level and object-level security configurations with their test cases.
  • Deployment pipelines wired between development, test and production.
  • A rebuilt gateway configuration and a refresh alerting setup that reaches a person.
  • A tenant inventory: every workspace and report with owner, usage and retirement decision.
  • A prioritized backlog of the subject areas still to be modelled.

Who this is for

Organizations of roughly 100 to 5,000 people with Power BI already in use, several source systems, and a growing gap between the numbers on the slide and the numbers in the system. It is frequently the first engagement, and it often surfaces that the real constraint is upstream, at which point Microsoft Fabric implementation is the honest next step rather than more modeling. Where reporting carries regulated data, we design the security model alongside compliance architecture.

Who this is not for

If you have no data platform, no clean source and no agreement on definitions, a semantic model will encode the disagreement rather than resolve it. Fix the definitions first, even if that takes a month of meetings we are not in.

If what you want is a specific report built by Friday, hire a contractor. That is a legitimate need and this is not the engagement for it.

If your organization treats Excel exports as the deliverable and will keep doing so regardless of what is published, the governance work will not stick. We would rather say that at the proposal stage than discover it at month four.

Questions we get

We already have Power BI. What would you actually change?

Usually three things. We consolidate overlapping models into a small number of certified ones, move the business logic out of report-level measures into the shared model, and put deployment pipelines between development and production so a change stops being a file someone republishes on a Friday. The report count normally falls by half.

Do we need a Fabric capacity or a Premium license?

Often neither, at first. Pro licensing covers a surprising amount if the models are built well and the refresh volumes are modest. Capacity becomes necessary for large models, Direct Lake, paginated reports or external sharing at scale. We model the cost both ways and show you the crossover point rather than defaulting to the larger license.

Can you enforce that a regional manager only sees their own region?

Yes, with row-level security defined in the semantic model and driven by Entra ID group membership, so access follows the HR change rather than a manual list. Where columns themselves are sensitive, such as salary, object-level security hides them entirely rather than returning a blank.

Who maintains the reports afterwards?

Your team, and that is the design goal. The shared model is documented, the measures are named and described in the field list, and we run build sessions with your report authors during the engagement rather than a handover presentation at the end.

Our refreshes fail overnight and nobody notices until 9am.

That is a gateway and alerting problem more often than a Power BI problem. We rebuild the gateway configuration with a clustered gateway rather than a single machine under someone's desk, set refresh failure alerts that reach a person, and put the sensitive credentials in a managed store instead of in a datasource someone configured in 2022.

Can you fix the fact that two reports show different revenue?

We can show you exactly why, usually within a day, because the two definitions are visible once the models are read side by side. Deciding which definition is correct is your call. We build whichever one you choose into the certified model so the argument does not recur every quarter.

Have a question about this work?

Three fields. An architect reads it and answers within one business day.

Every field is needed.

We reply to this address. Nothing else is sent to it.

The goal, the deadline, and what is in the way. Three lines is plenty.

What you send travels over TLS to our own Azure Function in Canada East and lands in our own Odoo CRM in Montreal. No third-party form script, no advertising cookie. We keep it to answer you, and delete it after twenty-four months if nothing comes of it. Privacy policy.

Bring us the workload. We bring the architecture.

Thirty minutes, one architect, no deck. Come with a problem and leave with an opinion you can act on.