Power BI is turning 10! Tune in for a special live episode on July 24 with behind-the-scenes stories, product evolution highlights, and a sneak peek at what’s in store for the future.
Save the dateEnhance your career with this limited time 50% discount on Fabric and Power BI exams. Ends August 31st. Request your voucher.
I have created one Role in powerbi as Global View without any conditions,rules or DAX.
Global View role is where i have added one group mail (CA 734 National@outlook.com )
(only in the group list users should access and see the report) non group users when the click powerbi url, see the report they should get error as you dont have access to Report/Dataset.
now the problem i am getting is when any new user email added to the Group mail or User removed from the Group mail then the RLS should work automatically(1. user removed from the group should not see the report/data.
2. new user added to the group mail should have access to see the report dynamically) without any Powerbi Security update.
when user is removed from the Group still he is able to access the report . how can it is solved??
Solved! Go to Solution.
Hi @VGL321 ,
In your Power BI setup, you've created a role called "Global View" with no DAX filters, and you've assigned a group mail CA 734 Daily Sales - National to this role. Your expectation is that only users who are members of this group should be able to access the report or dataset, while others should receive an error saying they do not have access. The issue arises when users removed from the group are still able to view the report, which defeats the purpose of dynamic security.
The root of this problem is typically tied to how Power BI and Azure Active Directory (AAD) handle group memberships. Power BI uses AAD to validate group membership, but this validation can be delayed due to caching. It may take up to an hour or more for membership changes—like removing a user from a group—to propagate across services and be reflected in Power BI. Additionally, if your group is a regular mail-enabled distribution list rather than an AAD Security Group or a Mail-enabled Security Group, Power BI may not recognize membership changes dynamically. To ensure proper enforcement, the group must be a recognized AAD Security Group.
Even with the correct group type, access control must be strictly managed through this group. If any user has been granted direct access to the report or dataset, or holds a workspace role such as Viewer or Member, they might still be able to access the report regardless of RLS. Make sure that no individual users outside the group have direct permissions on the workspace, dataset, or via a published Power BI App. If you are deploying the report via an app, re-publishing the app after group updates may help reflect the latest permissions.
As a more controlled alternative, you can manage RLS through a user access table inside your Power BI model. In this approach, you'd maintain a table with email addresses and define the RLS rule using DAX, for example:
[UserEmail] = USERPRINCIPALNAME()
In your data model, the UserEmail column would contain the list of authorized users. This method bypasses AAD group sync delays and gives you full control over who can see the report. However, it requires regular maintenance of the access table and can be less scalable for larger groups.
To resolve your issue, first ensure the group used in RLS is a proper AAD Security Group. Then remove all direct access from users outside the group. Allow some time for group membership changes to sync across AAD, and ask users to sign out and sign back into Power BI if access behavior seems incorrect. This should restore the expected dynamic behavior where only current group members can access the report.
Best regards,
Hi @VGL321 ,
In your Power BI setup, you've created a role called "Global View" with no DAX filters, and you've assigned a group mail CA 734 Daily Sales - National to this role. Your expectation is that only users who are members of this group should be able to access the report or dataset, while others should receive an error saying they do not have access. The issue arises when users removed from the group are still able to view the report, which defeats the purpose of dynamic security.
The root of this problem is typically tied to how Power BI and Azure Active Directory (AAD) handle group memberships. Power BI uses AAD to validate group membership, but this validation can be delayed due to caching. It may take up to an hour or more for membership changes—like removing a user from a group—to propagate across services and be reflected in Power BI. Additionally, if your group is a regular mail-enabled distribution list rather than an AAD Security Group or a Mail-enabled Security Group, Power BI may not recognize membership changes dynamically. To ensure proper enforcement, the group must be a recognized AAD Security Group.
Even with the correct group type, access control must be strictly managed through this group. If any user has been granted direct access to the report or dataset, or holds a workspace role such as Viewer or Member, they might still be able to access the report regardless of RLS. Make sure that no individual users outside the group have direct permissions on the workspace, dataset, or via a published Power BI App. If you are deploying the report via an app, re-publishing the app after group updates may help reflect the latest permissions.
As a more controlled alternative, you can manage RLS through a user access table inside your Power BI model. In this approach, you'd maintain a table with email addresses and define the RLS rule using DAX, for example:
[UserEmail] = USERPRINCIPALNAME()
In your data model, the UserEmail column would contain the list of authorized users. This method bypasses AAD group sync delays and gives you full control over who can see the report. However, it requires regular maintenance of the access table and can be less scalable for larger groups.
To resolve your issue, first ensure the group used in RLS is a proper AAD Security Group. Then remove all direct access from users outside the group. Allow some time for group membership changes to sync across AAD, and ask users to sign out and sign back into Power BI if access behavior seems incorrect. This should restore the expected dynamic behavior where only current group members can access the report.
Best regards,
Check out the July 2025 Power BI update to learn about new features.
This is your chance to engage directly with the engineering team behind Fabric and Power BI. Share your experiences and shape the future.
User | Count |
---|---|
23 | |
10 | |
10 | |
9 | |
7 |