RLS Issue in PowerBI

Question

Hi Team,

I have implemented same RLS across several reports that use different semantic models.

• The RLS setup includes two security tables.
• RLS is working correctly for the majority of users.
• However, two users can see all data, rather than being restricted by the configured security rules.
• When testing RLS using the "View as" feature, I do not receive any warnings indicating that these users have Member or higher workspace permissions that could bypass RLS.
• These two users do not have overlapping permissions across the two security tables.
• Based on my review, I have not identified any obvious issues in the security configuration.

Could you please advise on what I might be missing or suggest any additional areas I should investigate?

Thanks,

Abhishek

Answer 1

Hi Abhishek ,

Since this forum is primarily intended for Microsoft 365 subscription, account, billing, and general business support questions, to ensure that you receive the most accurate and effective assistance, I recommend posting your question in the Microsoft Power Platform Community. In this forum, you'll get the most qualified group of respondents and other partners who read the forums regularly can share their knowledge or learn from your interaction.    

I apologize for redirecting you to a different community, as the members of this category primarily focus on Office 365-related topics and may not be best positioned to assist with this particular inquiry. To help you receive the most relevant guidance, I am directing you to the appropriate community where specialists in this area are more likely to provide targeted assistance.

I trust that the experts there will be able to offer more detailed insight into the RLS behavior you're experiencing.

Thank you for your understanding, and I hope you are able to find a resolution soon.

Answer 2

Check these areas first:

1. Semantic model permissions RLS is enforced only for users who have Read or Read + Build permission on the semantic model. It is not enforced for users who have Write permission, including users who are Admin, Member, or Contributor in the workspace. Since View as is not showing a warning, verify whether those two users have:
   • workspace Admin, Member, or Contributor role
   • per-item Write permission on the semantic model
   If either is true, they can see all data.
2. Multiple role mappings If a user is mapped to multiple roles, RLS filters are additive. That means the user sees the union of the allowed rows across roles. In Power BI, the “once denied always denied” principle does not apply. Even if the two security tables do not appear to overlap, confirm that these users are not being assigned to multiple roles directly or through security group membership.
3. User mapping values When a specific user sees no filtering or unexpected filtering, confirm that the user-mapping table contains the correct values for USERPRINCIPALNAME() or USERNAME(). In the Power BI service, both USERNAME() and USERPRINCIPALNAME() return the user’s UPN. A mismatch caused by an incorrect stored value or a changed user account can cause unexpected behavior. A practical test is to add a measure using USERNAME() and place it on a card visual to confirm the identity value being evaluated.
4. Model relationships and filter propagation If RLS behaves differently for only some users, review the model design:
   • confirm relationships between the security tables and fact/dimension tables are correct
   • confirm RLS filters propagate through active relationships
   • confirm Apply security filter in both directions is set correctly where required
   • confirm the security tables contain the expected rows for those two users
5. Validate in the service correctly Use Test as role in the Power BI service to validate the role membership and filtering behavior. For dynamic RLS, confirm the mapping table matches the values returned by USERPRINCIPALNAME() or USERNAME().

A focused troubleshooting path for these two users is:

1. In the workspace, verify they are Viewer only.
2. On the semantic model, verify they do not have Write permission.
3. Check whether they belong to any Entra ID or security groups that are assigned to additional RLS roles.
4. Add a temporary USERNAME() measure to confirm the exact UPN seen by the service.
5. Review the two security tables for incorrect or unexpected values for those UPNs.
6. Review relationship direction, active relationships, and whether Apply security filter in both directions is needed.

If these users are anything other than Viewer, or have semantic model Write permission, that is the most likely reason they can see all data.

---

References:

• Row-level security (RLS) with Power BI
• Row-level security (RLS) guidance in Power BI Desktop
• Power BI implementation planning: Report consumer security planning