Permission Levels in Microsoft Fabric
In Microsoft Fabric, permissions can be assigned at two levels: workspace and Lakehouse. Each level controls access to different components, such as the Lakehouse itself, SQL Endpoint, or the Semantic Model.
This blog post will walk you through both levels and explain how to manage access effectively—step by step.
Workspace Level Permissions
Workspace Level Permissions
Lakehouse Level Permissions
Lakehouse Level Permissions
If a user doesn’t have specific permissions assigned to either the workspace or the Lakehouse, they won’t be able to see the workspace at all. Additionally, the Lakehouse will not appear in the OneLake Catalog.
Additional Permissions and Their Impact
In Microsoft Fabric, it’s possible to assign additional permissions directly at the Lakehouse level. These permissions apply not only to the Lakehouse itself but also to its associated components: the SQL Endpoint and the Default Semantic Model.
Depending on how these permissions are configured, users may be able to read data, run queries, or access reports—even without having access to the workspace.
We’ll go through the specific permissions for each component later in the post.
Impact of Additional Permissions
Default Semantic Model Permissions
Can Be Lost
If you assign item-level permissions (at the Lakehouse level), which apply to the Lakehouse, SQL Endpoint, and Default Semantic Model, and then later assign and remove workspace-level permissions, you might encounter unexpected behavior.
In this case, permissions for the Lakehouse and SQL Endpoint will remain, but permissions for the Default Semantic Model will be reset and removed.
So if you’re relying on custom access to the Semantic Model, make sure to double-check permissions after any changes to workspace roles.
When you assign the Read role to a user at the Lakehouse level, the same permission is automatically applied to the SQL Endpoint and the Default Semantic Model. It’s not possible to assign the Read role to these components individually—so we’ll cover their behavior together in this section.
Here’s what the Read role allows:
OneLake Catalog: The user can see the Lakehouse listed in the catalog.
OneLake Catalog with Read Permissions
SQL Endpoint: The user can view the structure of the tables (schema), but they do not have SELECT permission—so data cannot be queried.
OneLake Catalog SQL Endpoint Read Permissions
SQL Endpoint Read Permissions
SSMS Connection: It’s possible to connect to the SQL Endpoint using SQL Server Management Studio (SSMS), but no tables are visible.
Notebook in Another Workspace: You can attach the Lakehouse to a notebook located in a different workspace (where you do have access). However, you still can’t see the list of tables inside the Lakehouse.
Notebook Read Permissions to the Lakehouse
Removing Read Access Removes It Everywhere
If you remove the Read permission from a user at the Lakehouse level, it will also be removed automatically from the SQL Endpoint and the Default Semantic Model.
SSMS Requires Specifying a
Lakehouse to Connect
When connecting to the SQL Endpoint using SQL Server Management Studio (SSMS), and you don’t have access to the full workspace, you must specify the Lakehouse name (i.e. database) in the connection string. Otherwise, the connection will fail—even if you technically have access to multiple Lakehouses. Once connected, you’ll still be able to see all Lakehouses you have access to.
SSMS Specify the Lakehouse Name
ReadAll Permissions on a Lakehouse
In contrast to the Read role, ReadAll provides more direct access to both metadata and data.
The ReadAll permission provides broader access than the standard Read role. When assigned at the Lakehouse level, it enables the following:
OneLake Catalog: You can see the full list of tables within the Lakehouse—not just the Lakehouse itself. (In contrast, SQL Endpoint with Read only shows table structure, but not the list in the catalog.)
OneLake Catalog Lakehouse with ReadAll Permissions
Lakehouse Access: You can view both the structure and the content of all tables within the Lakehouse.
Cross-Workspace Usage:
- You can attach the Lakehouse to a notebook located in a different workspace (where you have access). Once attached, you’ll see the list of tables, columns, and data types, and you can run Spark SQL queries to explore the data.
Notebook with Attached Lakehouse with ReadAll Permissions Spark SQL
- Alternatively, you can access data without attaching the Lakehouse by using its ABFSS path directly from a notebook in another workspace.
Notebook with ReadAll Permissions ABFSS Load
ReadData Permissions on the SQL Endpoint
The ReadData permission allows direct data access within the SQL Endpoint, including the ability to query tables using T-SQL.
With this permission:
You have SELECT access, so you can query data directly from tables using tools like SSMS (SQL Server Management Studio) or the SQL Endpoint in Fabric.
SSMS Select with ReadData Permissions
SQL Endpoint Select with ReadData Permissions
You can explore system views such as INFORMATION_SCHEMA, allowing you to see metadata about tables, columns, and other database objects.
In SSMS, you’ll see the list of tables, their structure, and you’ll be able to run SELECT queries without restriction.
Power BI Reports: This permission is also required to view data in Power BI reports that use a Direct Lake Semantic Model. Without ReadData on the SQL Endpoint, the report will load—but no data will be displayed.
Direct Lake Semantic Model Lineage
ReadAll Permission on the SQL Endpoint
Microsoft Fabric also supports assigning a ReadAll permission directly to the SQL Endpoint.
However, during my testing, I was not able to identify any clear effect of this permission. It does not seem to grant additional access beyond what is already covered by other roles such as ReadData.
If you’re aware of any specific use cases or documentation that explains its purpose, feel free to share in the comments.
ViewerRole on the Workspace
The Viewer role in Microsoft Fabric provides limited access, but includes one key capability by default:
you automatically get ReadData on all SQL Endpoints within the workspace.
This means:
You can query data (SELECT) from all Lakehouses in the workspace via the SQL Endpoint. - You can view data in Power BI reports based on Direct Lake Semantic Models, because they rely on the SQL Endpoint—and ReadData is already granted through the Viewer role.
- No additional configuration is needed—simply being a Viewer gives you sufficient access for exploring data via reports or direct T-SQL queries.
Contributor, Member and Admin Roles
For the purposes of this blog post, the Contributor, Member, and Admin roles can be treated the same—they all provide sufficient access to interact with Lakehouses in a meaningful way.
Starting from Contributor and above, users gain:
Write permissions on the Lakehouse — allowing them to modify or create tables.
ReadAll on the Lakehouse — which grants full visibility into table structures and data.
ReadData on the SQL Endpoint — enabling the use of T-SQL queries (e.g., via SSMS or the SQL editor in Fabric).
Spark support in notebooks — since they also have permissions to interact with the Lakehouse directly using Spark.
These roles are suitable for users who need to not only explore but also manipulate data using both SQL and Spark-based tools.
As you have seen, there are several ways to configure permissions in Microsoft Fabric—some more straightforward than others. The platform offers a lot of flexibility, but with that comes complexity, especially when the documentation does not yet cover all the nuances.
This post is not meant to be a complete guide, but rather a reflection of real-world scenarios I encountered while working hands-on with Lakehouse permissions. If it helps you avoid a few common pitfalls or better understand how roles interact across components, then it has done its job.
Fabric is evolving quickly, so staying curious and sharing practical insights will remain essential. If you have come across unexpected behaviors or smarter ways to manage access, I would love to hear about them.
