[Microsoft Fabric] Workspace/Artifacts Acces/Rights

[MathieuSGA]

We have a situation here and we can't quite master/understand the best way to achieve what we want to do...

In one `ws_fabric` workspace, let's say we have the following tree:

ws_fabric_bi
   |- topic_A
      |- SemAndReport
         |- sem_a
         |- report_a
   |- topic_B
      |- SemAndReport
         |- sem_b
         |- report_b

Let's say we have two list of users:
* `list_a`: through an audience, only them should be able to view 'report_a'
* `list_b`: should be able to:
   - import 'report_b' to be able to modify/add visuals in 'Power BI Desktop'
   - publish back to 'ws_fabric_bi'
   (- **without** having access to 'topic_A')

PS: We did not want to disrupt the solution you guys could provide by throwing hypothesis we add but...is using 'Sensitivity Label' a "best_practice" enabler ? 

[Poojara_D12 · Accepted solution]

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.

[MathieuSGA]

@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.

[v-hjannapu]

Hi @MathieuSGA,

Thank you  for reaching out to the Microsoft fabric community forum.
Thank you @DataVitalizer, for your reply regarding the issue.

If the users in list_b need to open report_b in Power BI Desktop and publish it back, then yes, they will need Contributor access on the entire ws_fabric_bi workspace. But the problem is with Contributor role, they will also see other content in the workspace like topic_A, which you don't want.

Currently, Power BI doesn't support item-level access inside the same workspace. So, you can't hide only topic_A from list_b if both are in the same workspace.

 Best solution Create two separate workspaces: One for report_a (for list_a)  , One for report_b (for list_b) , this way you can give list_b full edit access without giving them access to report_a or topic_A.

Regarding Sensitivity Labels they help protect data like stopping download or sharing, but they won’t help with controlling who can see which report. So they are useful, but not for this particular access issue.

Hope my suggestion gives you good idea, if you have any more questions, please feel free to ask we are here to help you.
If this post helps, then please consider Accept it as the solution to help the other members find it more quickly. Best Regards,
Harshitha.

[v-hjannapu]

Hi @MathieuSGA,
I hope the information provided above assists you in resolving the issue. If you have any additional questions or concerns, please do not hesitate to contact us. We are here to support you and will be happy to help with any further assistance you may need.

Regards,
Harshitha.

[DataVitalizer]

Hi @MathieuSGA 

If list_b needs to publish back to the workspace, they’ll need at least Contributor role at the workspace level which may expose list_b content, to handle this you will have to create a separate workspace each.

Did it work ? 👍 A kudos would be appreciated ‌‌📢 Mark it as a solution to help spreading knowledge

[MathieuSGA]

@DataVitalizer Just to be sure, did you meant:
"If list_b needs to publish back to the workspace, they’ll need at least Contributor role at the workspace level which may expose list_b list_a" ?

[DataVitalizer]

Hi @MathieuSGA 
Sorry for the delayed reply. Absolutely anyone with publishing rights to a workplace will be able to view its content

Did it work ? 👍 A kudos would be appreciated ‌‌📢 Mark it as a solution to help spreading knowledge