Forum Discussion
RLS not wokring In OneLake security
if you're using OneLake security directly, then yeah, defining access roles like eastregion makes sense.
the reason I mentioned USERPRINCIPALNAME() is mostly for cases where RLS is applied via views or SQL logic, not just OneLake-level security. sometimes the identity resolution behaves differently depending on how the access is evaluated—especially if you're mixing workspace roles with SQL-based filters.
but if you're managing it all through OneLake access control and it's working as expected, then you're probably good đź‘Ť just make sure the role assignments are syncing properly and the column names match exactly in your views or queries.
let us know how it goes
Hi Viswanadh0110 ,
we had a similar issue with RLS not kicking in while CLS was working fine. turned out a couple things were causing it:
first, make sure the column you're filtering on (like SalesTerritoryKey) actually exists in the view you're querying. sometimes views drop or rename columns and it throws that “invalid column” error.
also, RLS needs more than just Viewer role in some cases. try giving the user Build or even Contributor access just to test if that makes a diff.
one more thing—if you're using domain\username in your RLS logic, try switching to USERPRINCIPALNAME() instead. Fabric seems to prefer that format (like [email protected]).
hope this helps a bit. let us know if you get it working.
If my response resolved your query, kindly mark it as the Accepted Solution to assist others. Additionally, I would be grateful for a 'Kudos' if you found my response helpful.
HI burakkaragoz ,
We are trying to implement RLS & CLS using Onelake security.
- We have create one access role names eastregion where the users inside this role group will only be able to see east data in region column.
- And why are we again giving USERPRINCIPALNAME(), domain/usernme in onelake security.
- It is straight forward as to write a query in the access to use RLS & CLS.
if you're using OneLake security directly, then yeah, defining access roles like eastregion makes sense.
the reason I mentioned USERPRINCIPALNAME() is mostly for cases where RLS is applied via views or SQL logic, not just OneLake-level security. sometimes the identity resolution behaves differently depending on how the access is evaluated—especially if you're mixing workspace roles with SQL-based filters.
but if you're managing it all through OneLake access control and it's working as expected, then you're probably good đź‘Ť just make sure the role assignments are syncing properly and the column names match exactly in your views or queries.
let us know how it goes