Power BI Service

## Two objects travel in one file A Power BI Desktop file (`.pbix`) looks like a single document, but it contains two things the Power BI Service stores as separate workspace items. The first is the **semantic model** — the Power Query (M) queries, the tables and their relationships, calculated columns, DAX measures, row-level security role definitions, and, for an *import* model, the compressed columnar copy of the data itself. The second is the **report** — pages, visuals, slicers, bookmarks, themes and formatting. Publishing unpacks the file and creates both, wiring the report to the model. Microsoft renamed *dataset* to *semantic model* during the Fabric rollout, so older documentation, blog posts and interviewers will use both words for the same object. Treat them as synonyms and say so out loud if the interviewer uses the older term. ## What each item owns The division of responsibility is clean and worth memorising, because almost every Service question reduces to it: - **The semantic model owns data.** Source connections, stored credentials, the on-premises data gateway binding, the scheduled refresh, incremental refresh policy, RLS roles, and every measure in the model. - **The report owns pixels.** Visual definitions and layout, report-level filters, and any report-level measures added on top of a live connection. It stores no rows and no credentials. So you configure refresh on the model, assign RLS role membership on the model, and grant *Build* permission on the model when someone needs to create their own report from it. Fixing a wrong measure fixes it for every report over that model at once — which is the whole argument for a shared model. ## The live-connection case If the Desktop file was created with *Get data → Power BI semantic model*, or a live connection to Analysis Services, it has no model of its own. Publishing it creates exactly one item: a report bound to the model that already exists in the Service. This is the shape you want for governed content — one model, many thin reports, one refresh, one definition of each measure. The common anti-pattern is the opposite: five analysts each publish a full `.pbix` against the same warehouse tables. You now have five semantic models, five refresh schedules competing for the same source and the same capacity, five copies of "Net Revenue" that drift apart, and five places to fix an RLS bug. Recognising that outcome is what the question is really testing. ## Republishing Republishing a file whose report and model names match existing items overwrites them in place rather than creating duplicates; the Service prompts you before replacing. Configured credentials and the refresh schedule generally survive as long as the data sources still match, which is why "publish again" is the ordinary update path for a Desktop-authored model. Changing the source connection string, however, typically forces you to re-enter credentials on the model. ## Dashboards are a third thing A **dashboard** exists only in the Service. It is a single canvas of *tiles* pinned from one or more reports (and from Q&A, Excel and other sources). You cannot author one in Desktop and you cannot publish one. Because tiles are cached snapshots that update after the underlying model refreshes, a dashboard tile and the report page it was pinned from can legitimately show different numbers for a short window — a distinction that turns up constantly in "why is this number stale" questions. ## Apps and workspaces around all this Everything above lands in a **workspace**, a container with roles (Admin, Member, Contributor, Viewer). Workspaces are where authoring happens. For distribution you normally publish an **app** from the workspace, which packages selected items into a read-only experience for consumers. So the full chain is: Desktop file → workspace items (model + report) → optional dashboard → app for consumers. ## What a good answer sounds like "Publishing splits the file: the semantic model gets the queries, relationships, measures, RLS and imported data; the report gets the visuals. Refresh, credentials, gateway and RLS are model settings. If the file live-connects to an existing model, only the report publishes — and that's the pattern I'd push for, so one governed model serves many reports instead of every analyst shipping their own copy."