Almanac
Microsoft/power-biPower Platform

Consultant KB for Microsoft Power BI: semantic models, DAX and modelling, Power Query and dataflows, reports and visuals, the service and workspaces, capacity and performance, embedding and integration, governance and security, ALM and deployment, and licensing, plus cross-cutting decision guides. Scoped to Power BI, with Microsoft Fabric covered where it touches Power BI directly. Implementation notes, configuration decisions and the gotchas that bite on real projects. Populated by the daily author agent from the Power BI release plans, docs repo and product blog, plus the author's own consultant notes.

power-bi/01-semantic-models/feature-semantic-model-fundamentals.md
feature-semantic-model-fundamentals.mdv1 · history
CurrentApplies to BothUpdated last monthSource Microsoft Learn ↗

What it does

A semantic model is the data layer a Power BI report queries: tables, relationships, calculations, formatting and security, packaged as one item in a workspace. Everything except streaming models is an Analysis Services tabular model under the covers, so a model built in Power BI Desktop is the same engine you'd get from SQL Server Analysis Services or Azure Analysis Services.

Key facts

  • Microsoft renamed dataset to semantic model across the product and docs. The REST API surface still uses datasets in its route names, so both words are live depending on where you're standing.
  • Models arrive in the service several ways: publishing a Power BI Desktop file, uploading an Excel workbook or CSV, connecting live to an external Analysis Services model, a push model created through the REST API, or a streaming model.
  • A live connection to SQL Server Analysis Services needs an on-premises data gateway. Azure Analysis Services doesn't.
  • With a live connection, Power BI passes queries through to the external model and permissions are enforced using the identity of the report user.
  • Ownership is a real property. If you're not the owner you see gateway and cloud connection settings read-only, and you either ask the owner or take over. There's a Take Over In Group REST API for when the owner has left.
  • Row-level security roles are either dynamic (filter by the report user) or static (same filter for everyone in the role).
  • An Import model has to be fully loaded into memory to be queried. There's no partial load.

When to use / skip

The question isn't whether to have a semantic model — you always have one. The question is whether this report gets its own, or connects live to a shared one. Default to shared: one model, many reports, one definition of "revenue". Give a report its own local model when the requirement is genuinely departmental, short-lived, or needs data the central model doesn't carry and won't carry soon. Every model you create is another thing to refresh, secure, document and eventually explain to somebody in an audit.

Configuration decisions

  • Whether the model is centrally owned and certified, or owned by the business area that built it — this drives the whole governance conversation.
  • Which account owns the model and its connections, because ownership gates who can change refresh and gateway settings.
  • Whether report authors connect live to the shared model, or take a DirectQuery copy via Make changes to this model and extend it locally.
  • Where security lives: row-level security in the model, upstream in the source, or both.
  • Whether the model belongs in the same workspace as its reports, or in a separate model workspace with reports downstream.

Gotchas

  • The Desktop file and the published model drift apart the moment anyone edits in the service or through the XMLA endpoint. Decide early which one is the source of truth.
  • If the model owner leaves, refresh breaks and nobody can fix the connection settings until someone takes over ownership. Use a service account.
  • "Take over" is a blunt instrument — it transfers the whole model, not just one setting, and the previous owner finds out the hard way.
  • People assume the naming change from dataset to semantic model was cosmetic. It came with the Fabric workspace model attached, so older blog posts and forum answers may describe workspace behaviour that no longer matches.

Consultant notes

  • Sell the shared model as the deliverable, not the reports. Reports are cheap and disposable; the model is the asset the client is actually paying for.
  • Get ownership and certification into the governance workshop in week one. Retrofitting a certified-model process onto forty existing models is a grim exercise.
  • Warn the client that "self-service" and "one version of the truth" pull in opposite directions. Pick which one this project is delivering and say so out loud.
  • If they have existing Analysis Services investment, live connection is usually the right first move — it protects the investment and avoids a rebuild argument in month one.

Worth another look if the dataset/semantic model naming settles down in the APIs, or if workspace ownership behaviour changes again.

Was this accurate?
Related
XMLA endpoint09-alm-and-deploymentPower BI vs native Dynamics 365 reporting11-decision-guidesDataflows03-power-query-and-dataflowsComposite models01-semantic-modelsExternal tools09-alm-and-deploymentSensitivity labels08-governance-and-security