Item Permissions and Sharing

Open one item, not the workspace

A workspace role opens every item in a workspace. Often that is too much: an analyst needs one warehouse, or a manager needs one report. For that case Fabric has item permissions, and you give them by sharing.

Item permissions control access to one Fabric item and do not apply to other items. You can use item permissions to give a user access to a single item in a workspace that the user cannot access. The person does not become part of the workspace:

• A user who receives an item through sharing cannot see other items in the workspace and is not a member of any workspace role.
• Sharing a lakehouse grants access to the lakehouse without giving access to the workspace and the rest of its items.
• Shared recipients of a warehouse have access only to that warehouse, and not to other items in the same workspace.

This is the tool for least privilege. Suppose an engineer was a Contributor and now only needs to read one lakehouse. To follow least privilege, remove the user from the workspace role and share the single item, so the user can reach that item and nothing else in the workspace.

Know what a plain share gives

When you select Share on an item, a dialog asks who receives it and which extra permissions to add. If you add nothing, the recipient gets one permission only.

Sharing an item grants the Read permission for that item by default. Read lets the user see the metadata of the item and view any reports associated with it, but it does not give access to the underlying data in SQL or OneLake.

For a warehouse this is very concrete. If no additional permissions are selected, the recipient of a warehouse gets Read, which only allows a connection to the SQL analytics endpoint, the equivalent of CONNECT permissions in SQL Server. With Read alone, the recipient cannot query any table or view, and cannot execute any function or stored procedure.

For a lakehouse it is the same idea. By default, sharing a lakehouse grants Read on the lakehouse and on the associated SQL analytics endpoint. When you share an item, Read is always included.

So Read is a key to the front door, not to the rooms. The recipient can find the item, open it, and connect. The tables stay closed until something else opens them.

This is also why a common support case is not a fault. When users can open a shared lakehouse but cannot query data, check that they have the permission that matches their access path. The next section lists those permissions.

Add the right data permission

The sharing dialog offers extra permissions. Each one opens a different way of reading, so choose it by the tool that the recipient will use.

The labels change a little between the warehouse dialog, the lakehouse dialog, and older material. Read the permission behind the label: a SQL option gives ReadData, and a Spark option gives ReadAll.

ReadData is the SQL permission. With ReadData, the recipient can read all the tables and views within the warehouse in read-only mode. ReadData is the equivalent of the db_datareader role in SQL Server. In the SQL analytics endpoint of a lakehouse, the option Read all SQL endpoint data is equivalent to Read all data using SQL. The lakehouse sharing dialog can also show this option with another label. On a lakehouse, Read all with SQL analytics endpoint lets the recipient read data from the SQL analytics endpoint through T-SQL.

ReadAll is the lake permission. ReadAll is for a recipient who needs complete access to the files of the warehouse through the Spark engine. On a lakehouse, Read all with Apache Spark lets the recipient read lakehouse data through Apache Spark and OneLake APIs. A recipient with ReadAll can find the ABFS path to a file in OneLake from the Properties pane of the warehouse editor, and can use this path in a Spark notebook to read the data. Permission to subscribe to OneLake events is currently granted along with the Read all Apache Spark permission.

The key rule is that the two data permissions are independent. ReadData and ReadAll are separate permissions that do not overlap. One does not include the other, so give each recipient the permission that matches the way of reading.

The lakehouse shows this clearly. A user with only Read all with SQL analytics endpoint can access data with the SQL analytics endpoint URL, but cannot access the data with the lakehouse URL. If the user also needs access through the lakehouse URL, grant Read all with Apache Spark in addition.

Two more facts about ReadAll on a lakehouse:

• Granting the Spark read option on a lakehouse also adds the recipient to the DefaultReader OneLake security role of the lakehouse. The OneLake security lessons explain how to restrict that access.
• Both additional data access permissions grant access to all the data in the lakehouse by default.

The Build option lets the recipient create Power BI reports on the default semantic model.

Share first with Read, then grant in SQL

ReadData opens every table and view. Many requirements are narrower: this analyst may read two tables, not two hundred. For SQL access there is a standard pattern, and it uses Read on purpose.

To give granular access to specific objects within a warehouse, share the warehouse with no additional permissions, and then give access to the specific objects with the T-SQL GRANT statement.

Each half has a job. The share gives Read, so the user can connect. The GRANT statement decides which objects the user can query. A workspace role is the wrong tool for this need. Even the Viewer role reads all warehouse data with T-SQL by default. The lesson on SQL granular security in the warehouse teaches the statements; here the point is the pattern.

Read is not optional in this pattern. For a user to connect to a warehouse or SQL analytics endpoint, the user must have a workspace role or the item Read permission, and without Read the connection fails. If a user has no workspace role and no item permission, the connection to the SQL analytics endpoint is rejected, regardless of any SQL permissions that exist for that user. SQL permissions alone never let anyone in.

The order of the two steps is your choice, and it matters for security. To set up granular permissions before a user connects, define the permissions in SQL first, and then give access with a workspace role or with item permissions. In this order, the user sees the right objects from the first connection.

One detail makes this possible. When you run GRANT or DENY, Fabric creates the database user automatically. So you can grant to a person who has never connected. The lesson on SQL granular security in the warehouse covers this in detail.

The opposite order is weaker. After ReadData is given, access to some objects can be restricted further with the T-SQL GRANT, REVOKE, and DENY statements. But between the share and the restriction, the user can already read every table and view.

Check who can share

Not everyone who can edit an item can share it. The permission to share has its own name, Reshare, and the workspace role decides who has it at the start.

• Workspace Admin and Member roles can share by default.
• Workspace Contributor and Viewer roles can share a lakehouse only if they are granted the Share (reshare) permission on that lakehouse.

So when a Contributor says that the Share button is not available, the first check is this permission. The fix does not need a higher role. Admin and Member can allow others to reshare items. So one of them gives the Contributor Reshare on that one lakehouse.

Sharing has clear limits on what it can give:

• Sharing a lakehouse grants read access only, and does not grant workspace membership or write permissions.
• On a warehouse, the Write permission is not shareable.
• To let other users collaborate on a warehouse with read and write access, add them to a workspace role such as Member or Contributor.

The warehouse adds limits of its own:

• Shared recipients do not have permission to reshare a warehouse.
• Sharing a warehouse directly with a service principal is not currently supported.
• Sharing a warehouse is currently available only through the user experience.
• Shared recipients access the warehouse with the identity of the owner, so the owner of the warehouse must not be removed from the workspace.

Put the rules together when you read a scenario:

Manage and remove item permissions

After a share, you need a place to see and change what people have. That place is the Manage permissions page of the item. The Manage permissions page shows the users who have access through workspace roles or through item permissions.

On a warehouse, three actions remove access at different sizes:

• Remove access removes all item permissions.
• Remove ReadData removes only the ReadData permission.
• Remove ReadAll removes only the ReadAll permission.

So you can take away the Spark access of a recipient and keep the SQL access, without sharing again.

The same page repairs a share that was too wide. If a recipient got ReadData but should read only some tables, remove ReadData and keep Read. The recipient can still connect, and the T-SQL GRANT on specific objects decides what can be queried.

Changes are not instant for the user. When you provide item permissions or remove users, permission propagation can take up to two hours. The new permissions are visible in Manage permissions immediately. This produces a confusing picture: the page already shows the new state, and the user still works with the old one. Signing in again makes sure that the permissions are reflected in the SQL analytics endpoint. For a lakehouse, permission updates can also take up to two hours to propagate for signed-in users.

Give report readers what the report needs

Reports add one more step. A report on a warehouse is shared with a manager, and the manager has nothing else. Does the report show data? It depends on how the semantic model reads the warehouse.

• If a report on a warehouse uses DirectQuery mode, the recipient of the report needs ReadData on the warehouse, or granular SQL permissions on specific tables or views.
• If a report on a warehouse uses Direct Lake mode, the recipient of the report needs ReadData on the warehouse, or granular permissions on specific tables or views.
• If a report on a warehouse uses Import mode, the recipient of the report needs no additional permissions.

The reason is simple. In Import mode the data is imported into the semantic model, and the recipient has access to it there. In the other two modes the recipient needs access on the warehouse itself.

One fact makes the first row the usual case. Direct Lake is the default connection type for semantic models that use a warehouse or SQL analytics endpoint as a data source. So when a report on a warehouse is shared with no other step, expect that the recipient still needs ReadData or granular SQL permissions on the warehouse.

The same idea applies to a lakehouse. With Direct Lake, the report reads the data directly from the lakehouse, and the recipient of the report needs access to those files in the lake. One alternative is to switch the data source credential from single sign-on to a fixed identity that has access to the files in the lake.

And a report grant never opens the tables for direct queries. A recipient who views a shared Direct Lake report must also have OneLake data permissions to query the underlying Delta tables directly.

Count both paths before you say access is removed

Item permissions and workspace roles live side by side. When you share an item or change its permissions, workspace roles do not change. A share adds a path; it does not replace the path that was already there.

A user who receives a shared item can access it regardless of the workspace role that the user has. The reverse is also true, and it is the classic surprise. If item permissions are removed from a user who has the Viewer role in the workspace, the user can still open the item from the workspace and view its content.

To stop a workspace Viewer from viewing an item, removing the item permissions is not enough; the Viewer role in the workspace must be removed too.

Without a workspace role, the user cannot see that the item exists, and without item permissions the link to the item does not work. And the door can be opened again in a narrow way. A user with no workspace role can view a shared item through its link, without having access to the workspace.

The habit that follows is short. Before you say that access is removed, list every path that the person has, not only the one in front of you.

Key takeaways

• A plain share gives Read, and Read opens no data. On a warehouse, Read alone lets the recipient connect to the SQL analytics endpoint, like CONNECT, without querying any table.
• ReadData is the SQL permission. It opens all tables and views in read-only mode and is the equivalent of db_datareader.
• ReadAll is the Spark permission, and it is separate from ReadData. A lakehouse recipient who has only the SQL option needs the Spark option too before a notebook can read the data.
• For some tables only, combine a plain share with a GRANT in SQL. Define the SQL permissions first and share afterwards, so the user never sees more than intended. A share that already gave ReadData is repaired by removing ReadData.
• Admin and Member share by default. Contributor and Viewer need Reshare on the lakehouse.
• Permission changes can take up to two hours to propagate. Manage permissions shows them at once.
• Import needs nothing more for report readers. Direct Lake and DirectQuery reports on a warehouse need ReadData or granular SQL permissions.
• Two paths, two removals. Removing an item permission does not remove access that comes from a workspace role.