Forum Discussion
Power ParticipantBest way to manage Row-Level Security (RLS) across service areas without maintaining manual email ma
Hello HamidBee ,
Dynamic RLS using a mapping table is the common best practice. Can you source it from HR system? (like AD, SAP) or can you get data from IT or HR?
Hello !
Thank you for posting on MS Fabric community.
You assign users in your org to Azure AD security groups and in PBI, you don’t reference the group directly in DAX. but instead you can manage permissions at the workspace or app level or pull group memberships into a mapping table if you need row level filtering.
If you want to follow the best practices, you can use an HR data feed especially if your HR system already has a table of User belonging to department or service Area and often HR or IAM systems keep this up to date so you bring that table into PBI and use it as your RLS mapping table and then your role definition is simply:
[ServiceAreaCode] IN FILTER('UserServiceAreaMapping', 'UserServiceAreaMapping'[UserEmail] = USERPRINCIPALNAME())
Post ProdigyHi HamidBee
Dynamic RLS with Employee Attribute Table
If you have an employee master table in your data source:
[ServiceAreaCode] =
LOOKUPVALUE(
EmployeeMaster[ServiceAreaCode],
EmployeeMaster[Email],
USERPRINCIPALNAME()
)
Option 2:
HR/Organizational Structure Dataset
Connect Power BI to your HR system or organizational database:
- Create a separate dataset/table with: [Email] → [ServiceAreaCode] mappings
- Link this to your main data model
- Update your RLS rule to: [ServiceAreaCode] = LOOKUPVALUE(Users[ServiceAreaCode], Users[Email], USERPRINCIPALNAME())
- Schedule regular refreshes of this user mapping table
Benefits: Single source of truth, automatic updates when HR data changes, scalable across multiple service areas.
Let me know if this works
Best Regards,