Access Controls: Who Gets In
Implement workspace-level and item-level access controls to ensure the right people have the right permissions in your Fabric environment.
How does Fabric control access?
Think of a hotel.
Your room key opens your room (item-level access). But the hotel also has floors — the executive floor needs a different key card (workspace-level access). And within your room, the safe has its own combination (data-level security, covered in the next module).
Fabric works the same way. Workspace roles control who can enter the workspace and what they can do there. Item permissions control who can see or use specific items (a lakehouse, a report, a pipeline) — even if they’re not a workspace member.
Workspace roles
Every Fabric workspace has four built-in roles. You assign users, groups, or service principals to these roles.
| Permission | Admin | Member | Contributor | Viewer |
|---|---|---|---|---|
| View all items | Yes | Yes | Yes | Yes |
| Read data (SQL, Spark) | Yes | Yes | Yes | Yes |
| Create items | Yes | Yes | Yes | No |
| Edit and delete items | Yes | Yes | Yes | No |
| Share items externally | Yes | Yes | No | No |
| Manage workspace settings | Yes | No | No | No |
| Add/remove members | Yes | Yes (not Admins) | No | No |
| Delete workspace | Yes | No | No | No |
Exam tip: Contributor vs Member
The exam loves testing the line between Member and Contributor:
- Members can share items with people outside the workspace and manage (add/remove) other members (but not admins)
- Contributors can create, edit, and delete all items in the workspace but cannot share externally or manage membership
Pattern: “A user needs to create notebooks but should NOT be able to share data outside the team” → Contributor
Assigning roles
| Assignment Method | Example |
|---|---|
| Individual users | anika@shopstream.com → Contributor |
| Security groups | SG-DataEngineers → Member |
| Microsoft 365 groups | M365-FinanceTeam → Viewer |
| Service principals | sp-etl-pipeline → Contributor (for automated pipelines) |
Scenario: Ibrahim's role strategy
Ibrahim designs the role assignments for Nexus Financial:
| Workspace | Admin | Members | Contributors | Viewers |
|---|---|---|---|---|
| Prod-Risk | Ibrahim, Sarah (compliance) | Lead engineers (2) | — | Risk analysts (20), Traders (50) |
| Dev-Risk | Ibrahim | All engineers (12) | — | — |
| Analytics-Marketing | Marketing lead | BI developers (4) | Marketing analysts (8) | Executives (10) |
Key decisions:
- No Contributors in Dev — everyone is a Member so they can collaborate freely
- No Contributors in Prod — only leads (Members) can share; analysts and traders are Viewers
- Marketing analysts as Contributors — they create reports but shouldn’t share externally (client data sensitivity)
Item-level permissions
Sometimes workspace roles are too broad. You want someone to access one lakehouse without seeing everything else in the workspace. That’s where item-level permissions come in.
How item permissions work
| Concept | Detail |
|---|---|
| Share | Give a specific user or group access to a single item (lakehouse, warehouse, report, etc.) |
| Permission types | Read, ReadAll (SQL/Spark read), Write, Reshare, and Build (for semantic models) |
| No workspace role needed | A user with item-level permissions can access that item without being a workspace member |
| Link sharing | Generate a link that grants access — People in your org, People with existing access, or Specific people |
When to use item permissions vs workspace roles
| Scenario | Best Approach | Why |
|---|---|---|
| Team of 10 engineers all working on same content | Workspace roles (Member/Contributor) | They need access to everything — no point granting item by item |
| BI analyst needs access to one lakehouse for Power BI reports | Item-level permissions (ReadAll on lakehouse) | They don't need to see pipelines, notebooks, or other lakehouses |
| External auditor needs to read one specific report | Item-level permissions (Read on report) | Minimal access — only the specific item they need |
| Service principal runs a scheduled pipeline | Workspace role (Contributor) or item permissions | Depends on how many items the pipeline touches |
ReadAll permission
ReadAll is a specific item permission that grants SQL and Spark read access to all data in a lakehouse or warehouse. Without it, a user might see the item in the workspace but get “access denied” when they try to query it.
Exam tip: ReadAll vs Read
- Read = can see the item exists and view metadata
- ReadAll = can query the actual data using SQL endpoint or Spark
Exam pattern: “A user has Viewer role in the workspace but cannot query the lakehouse via SQL.” Fix: grant ReadAll on the lakehouse item, or — if this is a data-level issue — check RLS/CLS (next module).
Scenario: Anika shares a lakehouse externally
Anika at ShopStream builds a product catalog lakehouse that the recommendation team (a separate workspace) needs to read. Instead of adding them to her workspace, she:
- Shares the lakehouse item directly with the recommendation team’s security group
- Grants ReadAll permission (they need to query via Spark)
- Does NOT grant Write (they should never modify product data)
The recommendation team sees only the product catalog lakehouse — nothing else in Anika’s workspace.
A marketing analyst at Nexus Financial needs to create Power BI reports in the marketing workspace but should NOT be able to share those reports with anyone outside the team. Which workspace role should Ibrahim assign?
Anika shares a lakehouse with a data scientist. The scientist can see the lakehouse in Fabric but gets 'access denied' when running a Spark query. What permission is missing?
Which of the following can be assigned to a Fabric workspace role? (Select all that apply)
🎬 Video coming soon
Next up: Data Security: Control Who Sees What — row-level, column-level, object-level security and dynamic data masking.