Workspace and Item Access Controls

Choose the boundary before you choose the grant

Every access decision in Fabric starts with one question: how much should this person reach? Fabric answers it with two boundaries, and picking the wrong one is what produces both over-exposure and support tickets.

A workspace is a logical entity that groups Fabric items. Workspace roles control access to a workspace and all of its content — assign one and the person reaches every item inside. Item permissions control access to one Fabric item and do not apply to other items — assign one and the person reaches that item only.

The two are not alternatives to argue about. They are different sizes of door, and the requirement decides which one you open.

Climb the four workspace roles

Inside a workspace there are four roles, and they form a progression of responsibility. Each one adds a capability to the one before it, which is what lets you pick the smallest role that still does the job.

Read the progression as sentences and it becomes hard to confuse:

• Viewer can view all workspace content but cannot modify it.
• Contributor can view and modify all workspace content.
• Member can view, modify, and share all workspace content.
• Admin can view, modify, share, and manage all workspace content, including permissions.

The progression matters because requirements usually arrive as a ceiling, not a floor: "must be able to build pipelines, must not be able to hand the workspace to outsiders". That phrasing points at the least privileged role that still meets the operational requirement.

Two worked readings:

A user who holds none of these four roles cannot access the workspace at all.

Keep a workspace role inside its workspace

A workspace role is powerful but deliberately local. A workspace role applies only to its assigned workspace, not to other workspaces, the capacity, or the tenant. Admin in the Sales workspace is not Admin anywhere else.

That containment is what makes regional designs work. Give a regional lead a role in the region's workspace and the reach stops at the regional boundary; the same person needs a separate assignment, in a separate workspace, to touch another region.

Open one item without opening the workspace

Sometimes the person needs a single report, not a place to work. That is what item permissions are for: an item permission can give a user access to a single item even when that user has no workspace role.

The starting point of sharing is fixed. Sharing an item grants Read permission for that item by default. You can add more from there, but Read is what a plain share produces.

The pattern to recognize is this one: a user with no workspace role can open a directly shared item through its link without gaining access to the workspace. They follow the link, they see the item, and the surrounding workspace stays invisible to them because they cannot access it.

This is the appropriate design when a recipient needs a report — or another single item — but should not browse everything around it. Giving them Viewer instead would technically work and would also expose every other item in the workspace.

Know what item Read does not open

Sharing gives Read on the item, and Read is narrower than people assume. Item Read lets the recipient see item metadata and associated reports, but it does not grant access to underlying data through SQL or OneLake.

So the visual layer opens and the data layer does not. Deeper access requires the relevant compute-level or data permission — through the SQL analytics endpoint, the semantic model, or OneLake — rather than a generous reading of item Read.

DirectLake makes the split concrete. A report in DirectLake mode reads straight from the lake, so a DirectLake report recipient needs permission to the report and OneLake permission to query the underlying Delta tables directly.

The report grant and the data grant solve different parts of the same access path:

1. Item Read on the report — the recipient can open it.
2. OneLake permission on the tables — the recipient can query those tables directly.

Neither substitutes for the other. Granting Read on the report a second time changes nothing, and neither does a workspace role somewhere else: a workspace role is confined to its own workspace and cannot reach these tables from outside it.

Evaluate the two paths together

Workspace and item grants coexist rather than replace each other. Sharing an item or changing its item permissions does not change the recipient's workspace role. The share adds a path; it does not rewrite the one that already existed.

The consequence is the classic surprise: removing one grant might leave another valid path wide open. A workspace Viewer can still view an item after direct permissions on that item are removed because the workspace role already grants view access. From the workspace, the item is still there, still openable, still readable.

To actually stop the access, close both doors: remove the workspace grant as well as any direct item grant. With no workspace role, the person can no longer see that the item exists; with no direct grant, the shared link stops working too.

The audit habit that follows is short: before declaring access removed, list every path the person holds, not just the one you happen to be looking at.

Key takeaways

• Workspace roles apply across every item in one workspace, while item permissions target one item. Pick the boundary first, the grant second.
• Contributor modifies content, Member also shares it, and Admin also manages workspace permissions, with Viewer read-only underneath them.
• A workspace role never leaves its workspace: not to other workspaces, not to the capacity, not to the tenant.
• Item Read does not by itself grant SQL or OneLake access to underlying data, so a DirectLake recipient needs the report grant and the OneLake grant.
• Removing direct item access does not override access inherited from a workspace role — close every path, or you have closed none.