Forum Discussion
Advocate IIHow Do You Maintain Consistent Row-Level Security Across Power BI Deployment Environments?
When Power BI solutions move from development to testing and production, maintaining consistent Row-Level Security (RLS) can become challenging, especially when different teams, user groups, and workspace permissions are involved.
For example, a report may work correctly in the development workspace but expose unexpected access issues after being deployed to production.
I'm interested in understanding how other Power BI developers and administrators handle this in real-world environments.
A few things I'd like to learn:
- How do you maintain consistent RLS roles across development, testing, and production?
- Do you manage security through Microsoft Entra ID groups or assign users individually?
- How do you validate role permissions after deploying semantic models?
- Are you using deployment pipeline rules or automated testing to prevent security configuration drift?
What practices have worked best for your teams when managing RLS in larger Power BI environments?
I'd especially appreciate practical experiences and lessons learned rather than just documentation-based recommendations.
5 Replies
- GilbertQ
Super User
What I have done when doing this is the RLS is consistent with where I am doing it in development, testing or production to ensure that the RLS is always working as expected.
I only use intra RD security groups for securing the RLS because it is much easier to manage a group than individual users. In terms of validating the semantic model, this is done using the test as role which you can do within the power BI service as well as I typically get another test created in order to ensure that it is working as expected when I make RLS changes to the model.
- benibix
Helper V
I can only give you what the docs say, not experience from my own projects. They explain most of this drift. A deployment pipeline copies the role definitions with the model, but role assignment isn't copied, and neither are workspace permissions. So each stage has the roles, and you have to add the Entra groups to them again on the model's Security page. Do that as a fixed step after every first deployment.
When a user sees too much, check their workspace role first. RLS only applies to Viewers. Admin, Member and Contributor bypass it. A role with no members just shows no data.
To validate, use Test as role in each stage. Dynamic rules on USERPRINCIPALNAME() need a check with a real Viewer account, since Test as role uses your own identity.
https://learn.microsoft.com/en-us/fabric/cicd/deployment-pipelines/understand-the-deployment-process
- Sahir_Maharaj
Hello codeautomation,
From my experience, the most reliable approach is to keep RLS role definitions consistent across environments while managing user assignments separately.
I'd recommend defining your roles in the semantic model, using Microsoft Entra security groups instead of individual users, and assigning environment-specific groups to those roles in Power BI Service.
One important point... deployment pipelines don't copy RLS role memberships. They deploy model metadata, but security assignments remain specific to each environment.
I'd also recommend validating RLS after every deployment using Test as role, ideally with dedicated test accounts.
- maruthisp
Hi codeautomation,
I got an example dynamic RLS example based on AdventureWorks data which you find in the attached pbix file.
1. After developing Dynamic RLS in Semantic model, you need to create the TEST user in all environment and with all correct roles and permissions.
2. Depends on the Company standards, some uses GROUPS with users or individual users. I would prefer GROUPS with users makes life easier.
3.Security groups must be assinged to approapriate roles in each environment
4.Validate RLS after every deployment, I have seen some times it goes wrong and doesnt work.
Best Regards,
Maruthi
LinkedIn - http://www.linkedin.com/in/maruthi-siva-prasad/
X - Maruthi Siva Prasad - (@MaruthiSP) / X - uzuntasgokberk
I’d treat RLS as two separate parts of the release. Version the role definitions with the semantic model, then manage role membership in each environment. Deployment pipelines copy model metadata, including role definitions, but don’t copy role assignments or workspace permissions. I’d map an environment-specific Microsoft Entra security group to each role and keep the expected mappings in the repo so reviewers have something concrete to compare against. Deployment rules can point the model to the right data source or parameter values, including the source of a dynamic RLS mapping table. The group assignments are a separate check.
After deployment, I’d open the published app as a dedicated test account with the same access as a consumer. Test as role is useful for a quick check, but the real account verifies the group assignment, USERPRINCIPALNAME() mapping, and app access together. If someone sees too much, check for Admin, Member, or Contributor access in the semantic model’s workspace first. Then check overlapping RLS roles, since their permissions are additive.
For a release gate, I’d use three test cases with records known to exist. A North user sees North and zero South rows. A South user gets the reverse. A user in the dynamic RLS role with no mapping gets zero rows. Automate those assertions where your setup supports it, and keep the published-app check for end-to-end validation. Checking only that a report opens or shows data can miss the leak you’re trying to catch.
