Learn › Power BI & Fabric › 1 · Foundations

Workspaces and the four roles

A workspace is where Power BI permissions actually live, and it has exactly four roles that most people conflate. Get the role ladder straight, then separate it from per-item sharing and app distribution — three different ways to grant access, three different blast radii.

The four workspace roles (the ladder)

A workspace is a security boundary; assign people (ideally security groups) to one of four roles:

Role Can view Can edit/publish content Can manage members Can delete the workspace
Viewer Yes No No No
Contributor Yes Yes (create/edit items) No No
Member Yes Yes Yes (add others up to Member) No
Admin Yes Yes Yes (including other Admins) Yes

The role governs everything in the workspace at once. Viewer is the consume-only role — but remember the licensing rule: a Free user in a Viewer role can only actually open the content if the workspace sits on F64+ capacity (otherwise they need Pro). Role and licence are two separate gates and both must pass.

Three ways to grant access (do not confuse them)

  • Workspace roles — coarse, whole-container access; the editing/authoring surface. Assign groups here, not individuals.
  • Per-item sharing — share a single report or semantic model with a person via a direct-share link. Granular, but ungoverned at scale: shares accumulate invisibly and nobody remembers who has them.
  • Apps — the recommended distribution channel for read audiences. You publish the workspace's polished content as an app with its own audiences, and consumers get the app, not the workspace. This decouples 'who builds' (workspace) from 'who reads' (app audience).

The healthy pattern: a small Contributor/Member team builds in the workspace, the broad audience consumes via the app, and nobody uses per-item direct shares as the primary mechanism.

Failure modes

  • Everyone-a-Member. Handing Member (or worse) to the whole team means anyone can overwrite production content, change refresh credentials, or add outsiders. Contributor is almost always the right authoring role.
  • Direct-share sprawl. Ad-hoc per-item shares bypass the app model and become the shadow ACL nobody audits — the classic oversharing trap. Access outlives the reason for it.
  • Guest access via roles. Adding an external guest to a workspace role hands them the whole container; combined with 'Export data' or a loose tenant setting, data walks out.
  • Personal-group leakage. Content built in 'My workspace' can be shared but never governed — it has no roles at all.

What to watch (proofs)

  • Role census: Get-PowerBIWorkspace -Scope Organization -Include All enumerates every workspace and its users/roles — the map of who holds Admin/Member across the estate.
  • Individuals where groups belong: workspace access lists showing named users (not security groups) in Member/Admin — the ungovernable grant.
  • Direct-share inventory: the admin REST scanner (admin/workspaces/getInfo) returns per-item users, exposing direct shares that bypass the app model.
  • App audiences vs workspace: reconcile who consumes the app against who sits in the workspace — read audiences should not be workspace members.
  • Guests in roles: cross-reference workspace users against Get-MgUser guest accounts — external identities in any authoring role are a review item.

PowerShell for this concept

Discussion

No messages yet — start the thread.

Sign in with your email to join the discussion — we send a one-time link, no password.