Forum Discussion
Resolver IRLS on a PowerBI semantic model - OneLake Catalog
Hi CarlBlunck ,
Thanks for providing the additional details.
RLS continues to work even if the report is published to a different workspace and then shared, so workspace-level access is not a factor here.
The USERPRINCIPALNAME() function always returns the signed-in user’s UPN. If that value does not exist in the workemail column of your security table, the filter evaluates to FALSE() for all rows, which results in the user seeing a blank report. This is the expected outcome since RLS only allows data access to users that are present in the filter table.
It is also important to ensure that the role you defined in Desktop is actually assigned in the Power BI Service. If the role is not assigned, the user effectively has no access, and the report will appear blank.
Finally, since there is a many-to-many relationship between the RLS filter tables, that can cause filters not to propagate correctly and lead to unexpected or empty results. Redesigning the model to avoid many-to-many relationships in the RLS filtering path is generally recommended.
Hope this helps. Please reach out for further assistance.
Thank you.
Community SupportHi CarlBlunck ,
Thanks for confirming. Yes, based on what you described, my repro produced a different outcome. In my case RLS applied correctly in the second (thin) report.
A couple of additional points to double-check on your side, since they can affect whether RLS applies as expected:
>>Make sure the test user isn’t assigned a workspace role such as Admin, Member, or Contributor, because RLS will not apply if the user has those permissions.
>>After assigning the user to the RLS role in the service, ensure you click Save so the role assignment actually takes effect.
These can sometimes be overlooked and may explain the difference in behavior.
Would you be able to confirm how the test user was added to the report - only through RLS role assignment, or were they also granted a workspace role?
Thank you.
Resolver IHi v-veshwara-msft ,
Can confirm the test user isn't assigned a workspace role. The second (thin) report is published in a different workspace to the first report/semantic model.
RLS is applied by this security role and the test user is currently not in the table the security role is applied to.
And then that table is connected to the rest of the semantic model like this
When I test her access on the first report, she can't see anything.
Very weird! Any ideas?
Cheers
Carl
- v-veshwara-msft
Hi CarlBlunck ,
Thanks for providing the additional details.
RLS continues to work even if the report is published to a different workspace and then shared, so workspace-level access is not a factor here.
The USERPRINCIPALNAME() function always returns the signed-in user’s UPN. If that value does not exist in the workemail column of your security table, the filter evaluates to FALSE() for all rows, which results in the user seeing a blank report. This is the expected outcome since RLS only allows data access to users that are present in the filter table.
It is also important to ensure that the role you defined in Desktop is actually assigned in the Power BI Service. If the role is not assigned, the user effectively has no access, and the report will appear blank.
Finally, since there is a many-to-many relationship between the RLS filter tables, that can cause filters not to propagate correctly and lead to unexpected or empty results. Redesigning the model to avoid many-to-many relationships in the RLS filtering path is generally recommended.
Hope this helps. Please reach out for further assistance.
Thank you.
- v-veshwara-msft
Hi CarlBlunck ,
Just wanted to check if the response provided was helpful. If further assistance is needed, please reach out.
Thank you.