Get certified in Microsoft Fabric—for free! For a limited time, the Microsoft Fabric Community team will be offering free DP-600 exam vouchers. Prepare now
Could anyone point me to documentation or help me understand how security works with a semantic model that points to delta tables in a fabric lakehouse that I'd like to share with a group of users? I've created a delta table in a fabric lakehouse and a semantic model that references the table. I tried sharing the semantic model with a business user as they would like to create a variety of reports using this data. The user is able to open Power BI desktop and click Get Data > Microsoft Fabric (Preview) > Power BI datasets and they are able to select the semantic model that I've created for them. The model appears in Power BI in the data pane. Once the user selects a field, they get an error: "Couldn't load the data for this visual. You don't have permission to view the content of Direct Lake table."
I tried clicking ... on the Semantic Model and selecting manage permissions and adding the user there. They got the same error.
I tried clicking ... on the Lakehouse and selecting manage permissions and adding the user there. They got the same error.
I was able to allow the user to access the data by managing access on the workspace and adding the user as a viewer.
I was hoping to avoid giving the user access to the workspace as I didn't want the user to be able to see the other artifacts like pipelines, notebooks, lakehouse, or environment. I was hoping to just share the semantic model with the user. Is there a better way to do this?
One thing I thought to try is to create another workspace that only has the semantic model and give the user view access to that workspace. Then I could keep all the other fabric items that my user doesn't need to see hidden. Is this a common practice? Is there a better option?
Any suggestion or documentation that you could point me to would be greatly appreciated! Thank you in advance!
Solved! Go to Solution.
Hi, @AdamFry
Workspace Permissions:
Viewer Role: Provides read-only access to all content within the workspace, including datasets, reports, dashboards, and dataflows. This role is suitable for users who only need to consume data without modifying it.
Member, Contributor, Admin Roles: These roles have more permissions and can modify content within the workspace. Typically, you wouldn't want regular business users to have these roles if you want to restrict their access to just consuming the data.
Dataset Permissions:
You can share datasets (semantic models) with specific users or groups directly. This is done by managing permissions on the dataset itself and granting build permissions.
Lakehouse Permissions:
The lakehouse permissions control access to the data stored in the lakehouse. Granting access here allows users to read the data stored in delta tables.
Creating separate workspaces can be a good practice to segregate access and control visibility. Here's how you can do it:
Workspace A (Development): This workspace contains all your development artifacts like pipelines, notebooks, lakehouses, etc.
Workspace B (Consumption): This workspace contains only the semantic models (datasets) and reports that you want to share with business users.
Step 2: Share the Semantic Model
Grant Access to the Semantic Model:
Go to the dataset (semantic model) in Workspace B.
Click on the ellipsis (…) next to the dataset and select "Manage permissions".
Add the users or groups who need access to the dataset and grant them "Read" and "Build" permissions.
Ensure Users Have Read Access to the Lakehouse Data:
Go to the lakehouse in Workspace A.
Click on the ellipsis (…) next to the lakehouse and select "Manage permissions".
Add the same users or groups and grant them "Read" access to ensure they can access the data in the lakehouse.
Power BI Workspace Roles: Power BI Documentation on Workspace Roles
Manage Permissions for Power BI Datasets: Power BI Documentation on Managing Permissions
Azure Data Lake Storage Access Control: Azure Documentation on Access Control
Best Regards,
hackcrr
If this post helps, then please consider Accept it as the solution and kudos to this post to help the other members find it more quickly
Hello,
Idea with separate workspace will not work, as View role will not be related to Lakehouse but to semantic model only. For me granting access on Lakehouse level works just fine. Whatever delta talbes you include in your Direct Lake model, you must grant access to them on Lakehouse level as well. You could try the new RBAC feature:
Data Access Control Model in OneLake (Public Preview) - Microsoft Fabric | Microsoft Learn
Here is also a nice video from Guy in a Cube for RLS:
Leverage RLS with Direct Lake in Microsoft Fabric without access to OneLake (youtube.com)
Alternatively, you could grant access through SQL Endpoint, but I guess the point here is to leverage the Direct Lake and Direct Query.
Hello,
Idea with separate workspace will not work, as View role will not be related to Lakehouse but to semantic model only. For me granting access on Lakehouse level works just fine. Whatever delta talbes you include in your Direct Lake model, you must grant access to them on Lakehouse level as well. You could try the new RBAC feature:
Data Access Control Model in OneLake (Public Preview) - Microsoft Fabric | Microsoft Learn
Here is also a nice video from Guy in a Cube for RLS:
Leverage RLS with Direct Lake in Microsoft Fabric without access to OneLake (youtube.com)
Alternatively, you could grant access through SQL Endpoint, but I guess the point here is to leverage the Direct Lake and Direct Query.
Hi, @AdamFry
Workspace Permissions:
Viewer Role: Provides read-only access to all content within the workspace, including datasets, reports, dashboards, and dataflows. This role is suitable for users who only need to consume data without modifying it.
Member, Contributor, Admin Roles: These roles have more permissions and can modify content within the workspace. Typically, you wouldn't want regular business users to have these roles if you want to restrict their access to just consuming the data.
Dataset Permissions:
You can share datasets (semantic models) with specific users or groups directly. This is done by managing permissions on the dataset itself and granting build permissions.
Lakehouse Permissions:
The lakehouse permissions control access to the data stored in the lakehouse. Granting access here allows users to read the data stored in delta tables.
Creating separate workspaces can be a good practice to segregate access and control visibility. Here's how you can do it:
Workspace A (Development): This workspace contains all your development artifacts like pipelines, notebooks, lakehouses, etc.
Workspace B (Consumption): This workspace contains only the semantic models (datasets) and reports that you want to share with business users.
Step 2: Share the Semantic Model
Grant Access to the Semantic Model:
Go to the dataset (semantic model) in Workspace B.
Click on the ellipsis (…) next to the dataset and select "Manage permissions".
Add the users or groups who need access to the dataset and grant them "Read" and "Build" permissions.
Ensure Users Have Read Access to the Lakehouse Data:
Go to the lakehouse in Workspace A.
Click on the ellipsis (…) next to the lakehouse and select "Manage permissions".
Add the same users or groups and grant them "Read" access to ensure they can access the data in the lakehouse.
Power BI Workspace Roles: Power BI Documentation on Workspace Roles
Manage Permissions for Power BI Datasets: Power BI Documentation on Managing Permissions
Azure Data Lake Storage Access Control: Azure Documentation on Access Control
Best Regards,
hackcrr
If this post helps, then please consider Accept it as the solution and kudos to this post to help the other members find it more quickly
Check out the October 2024 Power BI update to learn about new features.
Learn from experts, get hands-on experience, and win awesome prizes.