This article is inspired by a question I encountered a couple of days ago on the Fabric community:

How can users create their own reports but with RLS applied?

Please be aware that all the aspects I cover in this article are not affected by the file format, meaning pbix vs. pbip, or if more workspaces are involved because Power BI deployment pipelines are in place. Next, as more and more Fabric workspaces come to life, for this article, it’s not important what licensing model is backing the workspace.

This article is solely about one question: what has to be done if a content creator needs to create and publish reports but the content creator is not allowed to see all the data?

This seems to be a simple requirement: develop content (finally publish the report), but with Row Level Security (RLS) applied.

To answer the question, I think it’s necessary to understand the following core principle, at least to some extent:

• Workspace roles

There are more reasons to separate the data from the content that are not due to RLS; I will cover these in a 2nd article in the next few days.

The different workspace roles come with different permissions, where the Admin role grants the most permissions and the Viewer role the least permissions to the user. It’s very important always to remember that the three roles, Admin, Member, and Contributor, can publish a Power BI report to the workspace; maybe even more important is the fact that users with one of these roles assigned can edit all items inside the workspace. These items, of course, include semantic models. These users must be considered Admins of the semantic models; for this reason, RLS will not be applied when users are accessing the semantic model. The next image shows workspace roles and a semantic model that is shared with a user from a different workspace:

The next section will discuss workspace roles and how these roles can interact with the semantic model after is’s been published to a workspace.

Because we are in the era of Microsoft Fabric it’s important to define the scope of this article because we can now create many more items than a couple of months ago. This article is focusing on the items semantic model and report.

At the current moment it’s not possible to create a new semantic model inside a workspace. Please be aware that I’m not talking about the default or a custom semantic model that is derived from a lakehouse in a Microsoft Fabric enabled workspace.

At the current moment it’s necessary to publish a report containing the semantic model to a workspace to “create” the model. When the pbix (or pbip) file is published to the workspace, not only the semantic is created but also a report. As this whole article is about separating the data from the content, you might think the report is no longer needed. Because I do the separation for quite some time, I started to create sensemaking visuals like checking the existence of column values from the fact table in the corresponding dimension table. The next image shows the permissions of a semantic model. The permissions must not be confused with the security settings of the model.

The user Tom has permissions on the model that are inherited from the workspace role Contributor. These permissions allow to alter the model, even to delete the model, when the user Tom is accessing the model using Power BI Desktop he will be able to see all the data no matter of the defined RLS and Object Level Security (OLS).

Often I encounter the requirement that users need to be able to create their own reports but it’s necessary that these users see only the data with RLS and OLS applied. This requirement can only be achieved when these users have not workspace role assigned, meaning these users are not part of the workspace that hosts the model. These users need access to the model though. This can be achieved by removing the users from the workspace and adding Build permission to the model this is shown by the next images, basically it’s three screenshots, (1) shows the workspace access, (2) shows how to assign the build permission to a uses, and (3) show the permissions on the dataset.

I recommend using Microsoft Entra ID (fka Azure Active Directory) security groups instead of providing individual users with the needed permissions.

Now the user Tom is able to access the model from Power Bi Desktop, and RLS and OLS will be applied. But now Tom needs to be a contributor in a second workspace, otherwise he will not be able to publish the report. The next image shows the separation of a data workspace and content workspaces. Please be aware that the next image shows two content workspaces, this might be required because how the content will be shared with consumers and can not be solved using audiences.

Thank you for reading!