Forum Discussion
[Microsoft Fabric] Workspace/Artifacts Acces/Rights
Hi MathieuSGA
You're facing a common but nuanced scenario in Power BI workspace and access management—balancing visibility and edit permissions across topics and reports while maintaining isolation between user groups. In your ws_fabric_bi workspace, where topic-based folders (topic_A and topic_B) contain both semantic models and reports, you want to ensure strict segregation of access:
Users in list_a should only view report_a, ideally through an audience setting (e.g., via Power BI apps or shared views), and should not see or interact with anything from topic_B.
Users in list_b should be able to edit and republish report_b (requiring Build and Contributor rights), but must not have access to anything in topic_A.
The challenge here is that Power BI workspaces do not yet support folder-level permissions natively—permissions are applied at the workspace level, not the folder or sub-folder level. So, your best path forward would be:
Separate Workspaces: Create distinct workspaces for topic_A and topic_B, even if they are logically grouped under ws_fabric_bi. This allows you to assign granular permissions per workspace. You can still organize them under a shared naming convention or deployment pipeline for alignment.
Power BI Apps & Audiences: Use Power BI Apps to publish curated views of reports to specific audiences. list_a can be an audience within an app tied to the topic_A workspace, ensuring they only see report_a.
Permissions: Assign list_b users Contributor access to the topic_B workspace so they can download, modify, and republish report_b, while ensuring they have no access to the topic_A workspace.
Sensitivity Labels: While Sensitivity Labels are more about data governance (encryption, data loss prevention, classification), they do not control user access. However, they are a best practice for securing content—especially if data is exported or shared externally—but are not the solution to your access control problem in this scenario.
In summary, splitting topics into separate workspaces and using Power BI Apps with audiences is your best practice approach for isolating visibility and edit rights. Sensitivity labels are useful for data classification and compliance but won’t help with user-based access segmentation within a single workspace.
Poojara_D12 DataVitalizer
Seems like both of you went for the same idea.
We actually add a way around but what you are suggesting seems relevant !
Thanks for your time and response.
Just for the sake of curiosity:
sem_a was based on data from a Lakehouse (let's say LH_a) located in another workspace.
And the problem was that someone could not acces the paginated report based on that sem_a.
Editing access from list_a to LH_a did allow them to visualize the paginated report.
We are indeed using audience to limit the display of the paginated report based on sem_a and prevent list_b to visualize it.