Workspace and model topology

What it does

The design work of deciding how many workspaces a client needs, what goes in each, and where semantic models sit relative to the reports that use them. It's the decision that quietly determines your security model, your licensing bill and how painful deployment will be.

Key facts

Microsoft frames workspace planning around two questions: intent for collaboration, and intent for viewing. A workspace that exists for a small team to work together is a different object from one that exists to publish a finished app.
Workspace roles are Admin, Member, Contributor and Viewer. They're the primary access control, and they apply to everything in the workspace.
Apps are the distribution mechanism. A workspace can publish an app whose audience is separate from the workspace membership, which is how you avoid giving consumers workspace roles.
Workspaces are assigned to capacities. Any workspace, including My Workspace, can move to any capacity in the tenant.
Semantic models can be shared across workspaces — a report in one workspace can live-connect to a model in another, with Build permission on the model.
Both report and model must sit on a qualifying capacity for free-licensed users to view. Splitting them across capacities is a licensing trap, not just an inconvenience.
Workspace subfolders exist and are preserved by both Git integration and deployment pipelines, so folder structure is part of the topology decision, not cosmetic.
Deployment pipelines pair items between workspaces assigned to adjacent stages, so the dev/test/prod split is itself a topology decision.
My Workspace is per user, ungoverned by default, and can be assigned to a capacity by an admin.

When to use / skip

Do this properly on any engagement with more than one team producing content. The default pattern that survives contact with reality is separating shared semantic models from reports: a model workspace owned by whoever is accountable for the numbers, and report workspaces owned by the business areas that consume them. It costs a little more admin and it buys you the ability to change a report without a modelling conversation, and to change a model without hunting for every report that depends on it.

Don't over-engineer it for a small client. Three workspaces for a team of four analysts is bureaucracy, and they'll route around it. The trigger for splitting is more than one audience, more than one owner, or more than one release cadence — not tidiness.

The thing to be firm about: one workspace per department containing everything that department ever built is the pattern you'll inherit, and it's the one that makes everything else difficult. Security is all-or-nothing, deployment is impossible to stage, and nobody can tell which reports are production.

Configuration decisions

Whether shared models live in their own workspace or alongside the reports. Separate is the enterprise answer; combined is fine for a single-team solution.
How many environments — dev, test, prod — and therefore how many workspaces per solution. Multiply that by the model/report split and the count grows quickly.
Whether consumers get workspace Viewer roles or app access. App access is almost always better and it keeps the workspace membership meaningful.
Which workspaces sit on capacity, with the model-and-report rule in mind.
Who holds Admin on each workspace, because that's the real control over Git connections, pipeline assignment and access.
Naming convention. It sounds trivial until there are two hundred workspaces and a request to find "the sales one".

Gotchas

Splitting model and report across capacities breaks free viewing. The report opens for a Pro user in testing and prompts an upgrade for the actual audience.
Build permission on a shared model is a separate grant from workspace roles. Report authors who can see the workspace still can't connect until someone gives it to them.
Deployment pipeline pairing is workspace-based, so a topology change after the pipeline exists means re-pairing and often duplicate items.
Contributor is more powerful than clients assume — it can publish and overwrite. The gap between Contributor and Viewer is where most access incidents live.
Content in My Workspace is invisible to governance and belongs to a person, not the organisation. It becomes an incident when that person leaves.
Model ownership becomes a bottleneck once several report teams depend on one shared model. That's a working-practice problem the topology creates, and you should name it up front.

Consultant notes

Draw the topology before anyone builds anything. Retrofitting a workspace split onto live content is a migration project with permissions, apps and pipeline pairing all in scope.
The model/report split is the recommendation to fight for. Every other benefit — reuse, single version of the truth, controlled deployment — depends on it, and it's the hardest to add later.
Tie workspace ownership to a named person and a named business owner, not a team mailbox. Ownership vagueness is what leaves you with three hundred workspaces and nobody to ask.
Agree the naming convention on day one and enforce it in the first ten workspaces. It never gets cleaned up later.
If the client's existing estate is one workspace per department, don't propose a big-bang reorganisation. Pick the highest-value shared model, split that, and let the pattern spread.

Worth revisiting whenever workspace folders, roles or capacity assignment behaviour change — the topology advice hangs off all three