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.