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/05-service-and-workspaces/feature-workspaces-and-roles.md
feature-workspaces-and-roles.mdv1 · history
CurrentApplies to ServiceUpdated last monthSource Microsoft Learn ↗

What it does

A workspace is the container that holds semantic models, reports, dashboards, paginated reports and — on a Fabric-enabled tenant — everything else. Access to it is granted through four roles: Admin, Member, Contributor and Viewer, assigned to individuals or to groups.

Key facts

  • Four roles, and only four. Admin owns the workspace itself (rename, delete, manage all roles). Member can add people at their level or lower and publish or unpublish the app. Contributor creates and edits content. Viewer reads and interacts.
  • Members can add users at lower permission levels but can't change an existing user's role or remove anyone. Upgrading a Viewer to Contributor needs an Admin to remove them first.
  • Everything except viewing and interacting needs a Power BI Pro or PPU licence. Viewers can be free-licence users only when the workspace sits on capacity — Microsoft's current wording is P SKUs and F64 or larger; smaller F SKUs still need Pro.
  • Roles can be assigned to security groups, distribution lists and Microsoft 365 groups, and nesting works. Someone in several groups gets the highest role of the set.
  • A workspace holds up to 1,000 semantic models and reports. A user or service principal can belong to up to 1,000 workspaces.
  • Service principals can hold workspace roles and inherit the same permissions as users for API operations.
  • My Workspace is the personal workspace every user gets. It's a single-owner space with no roles to assign, and content in it is shared by direct sharing only.
  • Creating a workspace doesn't create a Microsoft 365 group behind it. All administration stays in Power BI, though you can point a workspace at a Microsoft 365 group's OneDrive separately.

When to use / skip

There's no skipping this one — every piece of content lives in a workspace, so the only real question is how many you have and who's in them. The usual failure is one workspace per department that everyone gets Member on, which quietly gives twenty people the ability to unpublish the production app. Default position: Admin for one or two named people, Member for the BI team, Contributor for anyone who builds, Viewer for nobody unless you're deliberately using workspace access as a distribution channel — that's what apps are for.

Configuration decisions

  • Whether workspaces are split by subject area, by lifecycle stage (dev/test/prod), or both — and whether you're using deployment pipelines, which pushes you towards the latter.
  • Whether consumers get access through the workspace Viewer role or through a published app. Apps are usually the answer at any real scale.
  • Whether Contributors are allowed to update the app. Admins can delegate this, and it's the difference between the BI team being a bottleneck and losing control of what ships.
  • Whether the tenant lets everyone create workspaces or restricts it to a group, set in the admin portal.
  • Which groups back each role. Named individuals age badly — use Entra security groups from day one.

Gotchas

  • Viewer isn't a data boundary. A Viewer with Build permission on the semantic model can export data and use Analyze in Excel, seeing everything in the model regardless of what the report shows. Hiding columns is tidiness, not security. RLS or OLS is security.
  • Disabling a user in Entra ID doesn't strip their workspace access records. The access stays until the account is hard-deleted. It's deliberate, but it makes access reviews look wrong.
  • Free-licence Viewers on capacity behave fine until someone assigns them a higher role as well — then they get prompted to upgrade. If you want free Viewers, make sure they aren't picking up a Contributor role through some other group.
  • Some special characters in workspace names break over the XMLA endpoint and need URL-encoding.

Consultant notes

  • Get the workspace and group design agreed before the first report ships. Retrofitting group-based access onto forty individually-assigned workspaces is a miserable week.
  • Warn the client that the Member role is more powerful than the name suggests. "Member" sounds junior; it can unpublish the app the whole finance team uses.
  • Push the dev/test/prod split even on small tenants. It costs almost nothing to set up and it's the only thing that makes deployment pipelines usable later.
  • If they're on Fabric capacity, note that the same four roles now govern lakehouses, warehouses and notebooks too — so the blast radius of Contributor is wider than it was in a Power-BI-only world.

Worth another look if the licence gate on free Viewers moves again, or once the P-to-F SKU transition settles.

Was this accurate?
Related
Workspace and model topology11-decision-guidesFree users and content viewing10-licensingPower BI apps05-service-and-workspacesAdmin portal and monitoring08-governance-and-securityTenant settings08-governance-and-securityPower BI licensing overview10-licensing