Forum Discussion
RLS - Users See No Data Due to Email Alias vs. USERPRINCIPALNAME Mismatch (Workspace App)
Thank you all for the thoughtful responses After further investigation, I want to share an update that may help others facing similar symptoms.
In our implementation, we do not rely on a security mapping table for RLS evaluation. Instead, our models resolve identity directly from the user's Active Directory, which means the email alias vs. UPN mismatch was not the root cause in our case.
The actual issue turned out to be a misconfigured security group that had been inadvertently added to the Workspace App audience with elevated privileges. This group's permission scope was conflicting with and overriding the expected RLS enforcement for a subset of users effectively causing them to fall outside the intended access boundary and return no data.
Once the security group was identified and removed, RLS resolved correctly for all affected users.
Thank you again.
Hi lamisghoualmi ,
1. What does USERPRINCIPALNAME() actually return for aliased users in Fabric?
Gives whatever email they clicked to log into your app (like [email protected]), not their main UPN ([email protected]).
2. Should the mapping table store the alias, UPN, or both?
Both emails, same person.
User123 | [email protected] | Dept A
User123 | [email protected] | Dept A
3.Is there a recommended pattern for handling this alias/UPN mismatch in RLS?
The Users table needs:
- UserID (like employee id)
- Email (both UPN + alias row entries)
- DeptAccess (Dept A, Dept B)
RLS DAX will be: [Email] = USERPRINCIPALNAME()
Hope this resolves your issue.
Thanks,
Pallavi