2.4.1. Workspace and Item-Level Access Controls
💡 First Principle: Workspace roles provide coarse-grained access (floor access); item permissions provide fine-grained control (individual room keys). The effective permission is the union of both—meaning someone can have item access without a workspace role.
Scenario: A workspace contains sensitive financial reports and general operational dashboards. All team members need the dashboards, but only Finance Managers need the financial reports.
Workspace Roles
| Role | Capabilities |
|---|---|
| Admin | Full control, manage membership, delete workspace |
| Member | Create, edit, delete items; share and allow resharing; add people as Member, Contributor or Viewer |
| Contributor | Create, edit and delete items; can't add people or manage workspace access |
| Viewer | View items only |
Roles can be assigned to individual users, Microsoft Entra security groups, Microsoft 365 groups, distribution lists and service principals. A user in several groups gets the highest role.
Item-Level Permissions
- Purpose: Grant access to specific items without workspace role
- Use Case: Sharing a single report with users outside the workspace
- Implementation: Item → Manage Permissions → Add users/groups
- Export is a separate control: tenant export settings (such as Export to Excel) and a report's own export setting can block exporting data even for a user who can view the report
Permission Interaction: Workspace + Item + Data
Understanding how permissions combine is critical for exam scenarios:
| User Has... | Can They Access Item? | Can They Query Data? |
|---|---|---|
| Workspace Viewer only | ✅ View all items | ✅ T-SQL reads through the SQL analytics endpoint (ReadData); no Spark or OneLake API access (no ReadAll) |
| Item permission only | ✅ That item only | ❌ No direct query |
| Workspace Member | ✅ All items | ✅ Yes (create/edit) |
| Item permission + SQL permissions | ✅ That item | ✅ Yes (if granted) |
Decision Framework: When to Use What
| Scenario | Use This | Why |
|---|---|---|
| Team needs full collaboration | Workspace Member/Contributor | Simplest for ongoing work |
| External user needs one report | Item permission (Viewer) | No workspace access needed |
| User needs to query lakehouse tables | SQL GRANT + workspace access | Data permissions are separate |
| Temporary access for audit | Item permission with expiry | Remove access automatically |
⚠️ Exam Trap: Workspace Viewer can read lakehouse and warehouse tables with T-SQL through the SQL analytics endpoint, but not through Spark, OneLake APIs or the Lakehouse explorer (that needs ReadAll). Sharing a single report grants no query access to the data underneath it. This distinction frequently appears in exam scenarios.
⚠️ Common Pitfall: Granting Workspace Admin when Member would suffice. Admins can delete the workspace and manage membership—capabilities most users don't need. Follow least-privilege principles.
