How would you structure Power BI workspaces and promotion for a shared semantic model used by many teams?

## The failure this design prevents The default trajectory of a Power BI tenant is one workspace per report, each with its own imported semantic model, each refreshing the same warehouse tables, each with its own version of "Net Revenue". Within a year nobody can answer a number without asking whose report it came from, refresh windows collide on the source, and a fix to a measure must be applied in eleven places. Every element of the structure below exists to prevent that outcome. ## Separate the model from the reports The central decision is to make the semantic model a **product with an owner**, published in a workspace whose Admin/Member/Contributor list is deliberately small — the BI platform team or the domain's data owners. Consuming teams do not get write access to it. What they get is **Build** permission on the model, granted to groups rather than individuals, which lets them create live-connected reports in *their own* workspaces, and use Analyze in Excel. The payoff: one refresh schedule and one gateway binding instead of N; one RLS implementation to review; one place where a measure's definition lives, so a fix propagates instantly to every report over it. The cost you must acknowledge honestly is throughput — teams now wait on the model owner for a new measure or a new table, and if that queue is slow they will fork. So the operating model has to include a fast, low-ceremony path for adding measures, and a tolerated escape hatch (report-level measures, or composite models where the platform genuinely can't keep up), rather than pretending nobody will ever need something you haven't built. ## Environments and promotion Treat the model like code. Maintain **dev**, **test** and **prod** workspaces with the same items, where the model's data source is parameterised so each stage points at the corresponding warehouse environment. **Deployment pipelines** automate that promotion with rules that swap connection parameters between stages; the feature is gated on the workspace's capacity, and capacity tiers have been restructured repeatedly, so confirm availability before designing around it rather than quoting a SKU. Where pipelines are not available, the fallback is a controlled publish from a version-controlled artifact — never a hand-edited production model. That implies source control. Model definitions should live in a repository (Git integration for workspaces, or an external-tools workflow that serialises the model), so changes are reviewed, diffed and revertible. "Who changed this measure and why" must have an answer that is not someone's memory. ## Discovery and trust signals A governed model that people cannot find loses to a copy that they can. **Endorsement** is the lever: mark the production model **Promoted** by its owning team, and **Certified** once it has passed whatever review your tenant defines — certification is normally restricted to a designated group precisely so the label means something. Pair it with naming conventions and, at scale, a catalogue view so the first search result is the right model. ## Distribution to consumers Consumers should never see a workspace. Reports are packaged into **apps** with audiences, so the group that reads the executive summary and the group that reads the operational detail get different content from one distribution point, and access is one auditable list per audience. Workspace roles stay for authors. ## Security Row-level security is defined once, on the shared model, and role membership is assigned to security groups rather than individuals. This is a strong argument for the shared-model shape: RLS implemented eleven times is RLS implemented wrong at least once. Include RLS role assignment in your access-review cycle, and test roles explicitly — a model with roles defined but nobody assigned filters nothing. ## Capacity and noisy neighbours Refresh of a large model and interactive querying compete for the same capacity resources. Decide deliberately whether the shared model's workspace sits on capacity separate from volatile self-service workloads, so an analyst's runaway model cannot slow the executive report. That is a cost decision as much as a technical one and is exactly the kind of tradeoff a principal is expected to own and to justify with measured utilisation rather than instinct. ## Governing the metric definitions themselves The hardest part is not topology, it is semantics. Changing what "active customer" means changes every report at once — which is the benefit *and* the risk of a single model. Put a lightweight change process around measure semantics: a named owner, a review for changes with business meaning, a changelog visible to consumers, and a deprecation path for measures being replaced. Also decide where a metric *should* be defined: if the definition is used by more than the BI tool — by notebooks, by an application, by a second BI tool — it probably belongs upstream in the warehouse or a semantic layer, with the model consuming it rather than owning it. ## The answer that lands "Model in its own workspace with a small write list and Build for analysts; team reports live-connected in team workspaces; dev/test/prod with parameterised sources and pipelines where capacity allows; the model definition in source control; certified endorsement so discovery favours it; apps with audiences for consumers; RLS once, on groups; capacity separation between the governed model and self-service. Then the real work: an owner and a change process for the measure definitions, and a fast path for new requests so teams don't fork the model to get unblocked."