For Dynamic Row Level Security do I still need to add members on power BI service?

[ananda31]

How can I fully implement Dynamic Row-Level Security (RLS) in Power BI without having to manually add users to the role in the Power BI Service under Semantic Model-> More options → Security → Add members?

Context:
I've implemented Dynamic RLS using a SQL database that contains user emails, and I'm using the USERPRINCIPALNAME() DAX function to filter data based on the logged-in user. This works as expected in Power BI Desktop using the "View as Role" feature.

However, in the Power BI Service, some users are unable to see the filtered data unless I manually add them to the RLS role. Since the filtering logic is already dynamic and based on the user's email, I was hoping to avoid this manual step.

Is there a recommended workaround or best practice to automate this process and ensure users are recognized by the RLS logic without needing to be explicitly added to the role? under Semantic Model -> More options → Security → Add members?

[Poojara_D12]

Hi @ananda31 

Even with Dynamic RLS, you must add users (or AAD security groups) to the role in Power BI Service under Semantic Model → Security. This step activates RLS. The filtering stays dynamic using USERPRINCIPALNAME(), but assigning users to the role is still required for it to work.

[v-kpoloju-msft · Accepted solution]

Hi @ananda31,
Thank you for reaching out to the Microsoft fabric community forum. Also @Cookistador, for his inputs on this thread. I have identified few workarounds that may help resolve the issue.

Thank you for your detailed question and commendable work on implementing Dynamic Row-Level Security (RLS) using a SQL-based user mapping and USERPRINCIPALNAME(). Your filtering logic is correctly configured.

Regarding your inquiry:

Even with Dynamic RLS, users must still be explicitly assigned to the RLS role in the Power BI Service under:

Semantic Model → More options → Security → Add members

This step activates RLS for those users. Once added, the DAX logic (like USERPRINCIPALNAME()) dynamically filters the data based on your SQL mapping.

To streamline the process of adding users, you can:

• Add an Azure Active Directory (AAD) security group to the RLS role.
• Manage user membership via the AAD group, which offers better scalability.
• (Optional) Utilize Microsoft Entra ID dynamic groups, if available in your organization, to automate group membership based on attributes like department or title.

If this post helps, please give us ‘Kudos’ and consider accepting it as a solution to assist other members in finding it more quickly.

Thank you for using the Microsoft Community Forum.

[v-kpoloju-msft]

Hi @ananda31,

May I ask if you have resolved this issue? If so, please mark the helpful reply and accept it as the solution. This will be helpful for other community members who have similar problems to solve it faster.

Thank you.

[v-kpoloju-msft]

Hi @ananda31,

I wanted to check if you had the opportunity to review the information provided. Please feel free to contact us if you have any further questions. If my response has addressed your query, please accept it as a solution and give a 'Kudos' so other members can easily find it.
Thank you.

[v-kpoloju-msft]

Hi @ananda31,

I hope this information is helpful. Please let me know if you have any further questions or if you'd like to discuss this further. If this answers your question, please Accept it as a solution and give it a 'Kudos' so others can find it easily.
Thank you.

[Cookistador]

you can have some delay, Azure AD group membership changes don't propagate to Power BI Service instantly

Do you have many rls groups or only one?
If you have only one, you can use all users

[ananda31]

I actually did check the data source and the user was a part of the groups already assigned to the RLS roles for that semantic model. Still they got an Access denied pop up stating that the user doesn't have access to the underlying dataset. The underlying dataset uses RLS

[Cookistador]

When you have to manually add someone as a member under the Semantic Model's security settings (Semantic Model -> More options → Security → Add members), it means those users aren't part of the groups already assigned to the RLS roles for that semantic model.

Typically, to make this easier and prevent individual additions – especially if your RLS covers everyone in the organization, or if the workspace itself already limits who has access – the recommended approach is to use a group that includes all relevant users. You can then assign this group to the RLS roles.

If you do not have this kind of group, you can also try to use the group all users