Why Does Viewer Access Require Permissions for All Dependent Workspaces in Microsoft Fabric?

[aayushiharalal]

Hello Everyone,

I have set up the following workspaces in Microsoft Fabric:

• Workspace 1: Contains the Lakehouse with all the data.
• Workspace 2: Contains the semantic model connected to the Lakehouse from Workspace 1.
• Workspace 3: Contains the report that uses the semantic model from Workspace 2.

I wanted to grant viewer access to User1 for the report in Workspace 3 and provided them viewer access to this workspace. However, this alone did not work, and I had to also grant viewer access to:

1. Workspace 2 (Semantic Model)
2. Workspace 1 (Lakehouse)

To investigate, I tried consolidating all components (Lakehouse, semantic model, and report) into a single workspace. Despite this, I found that the User1 still required access to the Worksapce. Granting access to individual components separately(Lakehouse, semantic model, and report) also did not resolve the issue.

This behavior seems counterintuitive since User1 is only expected to view the report and has no need to directly interact with the semantic model or Lakehouse.

Am I missing something here? Could someone explain the logic behind this access dependency or suggest a simpler way to manage access for report viewers?

Thank you for your help!
@frithjof , @Srisakthi , @olivs 

[Srisakthi]

Hi @aayushiharalal ,

This is good exploration to do. Even I along with my team did extensive separation of Fabric Items. What we tried is the following,

Workspace A - Data Engineering - restrict access to only data engineers

Wrokspace B - Collaboration workspace - restirct access to only poewrbi experts

1. Kept lakehouse, notebooks, data pipelines in Workspace A,  create Shortcut to Lakehouse (which is in workspace A), semantic model and report in workspace B. So that if someone wants to build self serve report it will be easy.

2. User 1 will not have access to Workspace A. But User 1 will have contributor access to Workspace B to build reports or semantic model. 

Viewer access is just for viewing Fabric Items, to access lakehouse data we need to give further access like Read all data using SQL analytics endpoint so that in Report data will be accessible.

Happy to discuss more. Let me know if you have more questions

Regards,

Srisakthi

[aayushiharalal]

Hello @Srisakthi 
Thank you so much for the answer. it means a lot.

[frithjof_v · Accepted solution]

I assume you're using a custom (new) direct lake semantic model.

I would look into the Fixed Identity option:

https://www.datazoe.blog/post/setting-up-rls-on-a-direct-lake-semantic-model#viewer-06v5q59667

The section about Fixed Identity is found between these sentences in the linked article above:

"The default connection from the Direct Lake semantic model to the Lakehouse is single sign-on.

(...)

7. Finally, go back to the workspace and refresh the semantic model."

If you use fixed identity, the end users don't need to have access to the lakehouse. You just share access to the report (which includes sharing access to the semantic model).

I would share the report (this automatically includes sharing the semantic model) via distribution app or item permission (report sharing). https://learn.microsoft.com/en-us/power-bi/collaborate-share/service-how-to-collaborate-distribute-d...

https://learn.microsoft.com/en-us/power-bi/collaborate-share/service-create-distribute-apps

Sharing reports via distribution app is considered a best practice in most cases, see link above.

You can apply RLS (and/or OLS) in the semantic model, to limit the users' access to the data in the semantic model, see the rest of the datazoe blog linked above.

I would not give workspace access to end users, it's unnecessary and provides too much access.

Here is some more about fixed identity: https://learn.microsoft.com/en-us/fabric/get-started/direct-lake-fixed-identity

[aayushiharalal]

Hello @frithjof_v 
Thank you so much for the detailed answer it is really helpfull and I was able to get my work done.