Help understanding security and sharing of semantic models

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.