2.1 Workspace & Item Security
Key Takeaways
- Fabric has four workspace roles — Admin, Member, Contributor, Viewer — and you should always grant the least privilege that meets the need.
- Contributor can create and edit items but cannot manage workspace membership or settings; only Member and Admin can manage access.
- Item-level permissions (sharing a single semantic model or report) let you grant access to one asset without exposing the whole workspace.
- OneLake data access roles add path-level (folder/table) read security on top of workspace roles for lakehouse data.
- Always prefer narrow item sharing over broadening a workspace role when only one asset needs to be shared.
Why Security Layering Matters
Quick Answer: Grant the lowest workspace role that accomplishes the task. Use item-level sharing when only one asset must be exposed. Add OneLake data access roles when you need folder/table-level control over lakehouse data. Broadening a workspace role to solve a single-asset problem is the classic wrong answer.
The Maintain domain frequently tests "who should get what" scenarios. The expected reasoning is always least privilege: pick the narrowest grant that satisfies the requirement.
The Four Workspace Roles
| Role | Can Do | Cannot Do |
|---|---|---|
| Admin | Everything: manage settings, capacity assignment, all access, delete workspace | — |
| Member | Add/remove users (up to Member), share items, edit all content | Change workspace-level settings reserved to Admin |
| Contributor | Create and edit items, publish reports, write data | Manage workspace membership or settings |
| Viewer | Read and consume content (view reports, query allowed models) | Create or edit any item |
A frequent trap: a user who must build reports and semantic models but must not manage who has access needs Contributor, not Member. Member is over-privileged because it can manage membership.
Item-Level Permissions
Sometimes only one asset should be shared — for example, an executive who needs one certified semantic model but should not see every item in the workspace. The correct approach is item-level sharing (share the single item with the needed permission, such as Read or Read + Build), not adding the executive as a Viewer of the whole workspace. Item permissions can also grant Build permission so a user can create their own reports on a shared semantic model without workspace access.
OneLake Data Access Roles
Workspace and item permissions are broad. For lakehouse data, OneLake data access roles (also called OneLake security roles) add path-level read control: you define a role that grants read access only to specific folders or tables within the lakehouse, then assign users or groups to it. This enforces data-folder scoping that a workspace role alone cannot express.
Decision Order for Sharing
- Does the user need only one asset? → Item-level share (least exposure).
- Do they need to build/edit broadly across the workspace? → Contributor.
- Do they need to manage other users' access? → Member (or Admin for settings).
- Do they need only certain lakehouse folders/tables? → OneLake data access role.
A finance director must explore one certified semantic model and build her own Power BI reports from it, but must not see any other item in the workspace and must not manage access for others. What is the best way to grant this?