Forum Discussion
The report cannot be viewed because the underlying dataset uses row level security
Hi All,
I need some help with this issue I am facing. So I used userprinciplename() and set up rls on PowerBI desktop and it works fine on the desktop when i use modeling -> view as -> username.
I published the report on a brand new workspace and gave viewer access to the workspace to one colleague as a test and shared a link to the report. He is getting this error "The report cannot be viewed because the underlying dataset uses row level security". Now I know that I can add them to the semantic model -> security -> add the person and they will have access but what if I eventually need to have 7000 users, will i need to give access to 7000 users individually if there is no active directory that exists for this group?
Hi svp1000
will i need to give access to 7000 users individually if there is no active directory that exists for this group?
Yes, you will need to do this if you do not use groups. You should use groups.
You can use the following groups to set up row-level security.
- Distribution Group
- Mail-enabled Group
- Microsoft Entra Security Group
Here is more information:
https://guyinacube.com/2020/02/25/can-you-use-groups-with-power-bi-row-level-security-rls/
2 Replies
- djurecic
Super User
Hi svp1000
will i need to give access to 7000 users individually if there is no active directory that exists for this group?
Yes, you will need to do this if you do not use groups. You should use groups.
You can use the following groups to set up row-level security.
- Distribution Group
- Mail-enabled Group
- Microsoft Entra Security Group
Here is more information:
https://guyinacube.com/2020/02/25/can-you-use-groups-with-power-bi-row-level-security-rls/
Hi, svp1000
Thanks for the reply from djurecic , please allow me to provide addition:
You can also try optimizing RLS, RLS filters can affect query performance, so it's critical to design your model efficiently.
Apply RLS filters primarily to dimension-type tables, which are typically small and contain attributes such as user, department, or region. Fact-type tables, which contain transactional data, should have fewer RLS filters.
Make sure your relationship is well-designed, as RLS filters spread through relationships. Follow the principles of star schema and maintain clear relationships between tables.How to Get Your Question Answered Quickly
Best Regards
Yongkang Hua
If this post helps, then please consider Accept it as the solution to help the other members find it more quickly.
