Forum Discussion
Bypass RLS through DAX in Manage roles section
Thanks AnthonyGenovese I tried the OR([user email] = userprincipalname(), [Team]="Admin") but its not working as expected i.e. its reacting the same as [user email] = userprincipalname().
If I create another role, will this ignore the existing [user email] = userprincipalname() RLS? not sure what I am missing...
Yah sorry. Its not exactly team="admin" I think you would have to write dax that looks at the userprincipal name, does a lookup to see if they are an admin, and if so, then returns true on the second part of that OR statement.
Personally, I would go the route of a different role. That is what it is there for. It is what we implement in our many RLS instances. The greatest thing about RLS is that security is additive. So if you have one restricted like you have, and then another role where someone gets full access, then the user does get full access. Basically, if you have multiple roles, and a user is in multiple roles, as long as they have access in one of those roles, then they have access.
If this post was helpful, please kudos or accept the answer as a solution.
~ Anthony Genovese
Need more PBI help? PM me for affordable, dedicated training or consultant recomendations!
Thank you for sharing your thoughts AnthonyGenovese ... I m not sure if I understand about multiple roles w.r.t. to "Admin" and "Employee" view in RLS, if you can provide some sample or guidance that would be much helpful.
Thanks,
AnthonyJoseph
They way we do RLS for admins, is we have an AD Group that all the admins are in. Then, we add a new role call admin, with read privilages. Add that AD group to that role and you are all done.
If you have to use a table like you described to find who the admins are, you have to do it in dax.
I approve doing this with an Active Directory Group.
