Forum Discussion
Tips/Ideas/Best Practices for Enterprise Level RLS
- 2 years ago
My lowest-maintenance method for RLS is to use the organizational hierarchy - so who reports to who - to filter the data. So the CEO can see everything, leadership can see things for everyone under them, managers can see their direct reports, and individual contributors can see only their own data. It's really easy to set this up if you have a source for the reports-to information - I did a tutorial here, it uses a single "role": https://youtu.be/Z0eeTTL7EhQ?si=_RCmATxfPgVAhzwW
I like to avoid manually-set roles wherever possible, they are just a nightmare to try to manage in a large org... if it's a requirement, then you have to do what you have to do - security groups help there to outsource the membership management, but using some attributes that already exist in your data is the easiest way to go in my opinion.
CoreyP , Email enabled AAD security group needs to be assigned to a role created in Power BI Desktop.
The role needs to be defined based on email/userprincipalname
Power BI- Row Level Security(RLS): Handle ALL, UserPrincipalName: https://youtu.be/KVLEnIUo4pc
- CoreyP2 years agoSolution Sage
Yeah, for sure. What I was hoping to do is have the stakeholder managed sharepoint list with something like this table. Then use that to assign the various roles to the rows of data to filter accordingly based on the UPN.
Role AAD Group Filter Fields Restriction Parameters VIP RLS - VIP Region No VIP RLS - VIP Customer No VIP RLS - VIP Branch No VIP RLS - VIP Metric No Sales Rep RLS - Sales Rep Region Yes UPN's region ( eg. AMER ) Sales Rep RLS - Sales Rep Customer Yes UPN's list of accounts Sales Rep RLS - Sales Rep Branch No Sales Rep RLS - Sales Rep Metric No