Tips/Ideas/Best Practices for Enterprise Level RLS

[CoreyP]

Hey All,

I was hoping to get some ideas from anyone with experience setting up RLS in an enterprise level organization. We have many different employees from all over the world working in different capacities. A requirement has been given that leadership would like to implement some dynamic RLS to restrict data to what the person viewing is allowed to see. 

To simplify this, I'm going to use roles and corresponding AAD security groups. What I'm thinking about now is the best way to 1. minimize the number of different roles and 2. manage the access rules of the roles. Ideally, the roles and access rules would be stored in our HR system of record and managed by HR. However, that will take time and a bit of effort. Until then, I'm hoping to construct a working POC model we can hopefully use when we're able to productionize in the HR system. 

I would like the stakeholders of the report(s) to own management of the access rules to alleviate the burden on the DnA team. Right now, what I'm thinking is having a roles and access rules dimension stored in Sharepoint. I can then use this in the model to determine what fields a particular role filters on, and assign accordingly to the AAD security group. ( Speaking of.. has anyone connected AAD data to PBI? Like user profiles or group membership type data..? )

Am I thinking about setting this up in the right way? Have you faced a similar challenge, and how did you end up doing it? Do you have any tips, tricks, recommendations, resources or links?

Thanks everyone

[christinepayton · Accepted solution]

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. 

[amitchandak]

@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

[CoreyP]

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