Skip to main content
cancel
Showing results for 
Search instead for 
Did you mean: 

Join us for an expert-led overview of the tools and concepts you'll need to become a Certified Power BI Data Analyst and pass exam PL-300. Register now.

Reply
mmcanelly
Helper I
Helper I

Best practices for managing user groups

We are in the process of rolling out Power BI at our company, and I am trying to determine what the best method will be to manage user groups and access to workspaces / data sets. My question here is more in regards to "what is the best philosophy" for managing user groups rather than what specific method (Azure AD, etc.) is useful.

 

For example, in another BI platform that we've used, we decided to manage user groups by department. So you've got the Accounting user group who in theory all have access to the same reports and data sets. However, that started getting a little messy pretty quickly because there were so many one-off scenarios where some users within a department actually needed access to different reports.

 

I have been going back and forth with what will be the cleanest and also the lowest-maintenance way to manage user groups in Power BI. Currently I'm leaning toward a setup like this:

  • "Power BI Content Viewer - <Workspace Name>" group - View access to specified Workspace
  • "Power BI Content Editor - <Workspace Name>" group - Contributor access to specified Workspace
  • "Power BI Data Viewer - <Dataset Name>" group - Read access to specified Dataset
  • "Power BI Data User - <Dataset Name>" group - Read, Build access to specified Dataset

While this is fairly clean, I'm not convinced it's the best way to do it because it still requires a lot of management to ensure everybody is a part of the correct groups (as opposed to a simplified setup like the "by department" method I discussed above).

 

Has anybody been through this process before, and are there any good philosophies out there on the best way to manage user groups?

1 ACCEPTED SOLUTION
lbendlin
Super User
Super User

Pivot your thought process from Power BI structure to business needs.

Use a separate user management tool that handles onboarding/training/periodic review and expiry/offboarding.

Provide extracts of that tool (user lists) to your Power BI developers so they can use these lists in the RLS and OLS design.

for Premium capacity: Do not give access to workspaces/reports/dashboards.  Only give access to apps, and try to only give access through distribution lists. 

View solution in original post

2 REPLIES 2
v-cazheng-msft
Community Support
Community Support

Hi @mmcanelly ,

 

There are four types of workspace roles including Admin, Member, Contributor and Viewer. Different role has different permissions to the workspace content. For more details, you could refer to Roles in the new workspaces in Power BI - Power BI | Microsoft Docs.

vcazhengmsft_0-1658218899528.png

 

To Edit the content such as reports, dashboards, users need to be Admin/Member/Contributors in the workspace. For Viewers, they only have view/read permission to these content. So if you could add users to different groups and make these groups one of these four workspaces roles, then these users are allowed to do the operations showed as above. There are four types of groups can be added to workspace as well. For the differences on these groups, please have a look at this official document: Compare groups - Microsoft 365 admin | Microsoft Docs.

 

As for Build/ Read permission to dataset, to access the report data, users need Read permission to the dataset and all these four kinds of workspaces roles will have such kind of permission. As for Build permission, users can create new content based on it, such as reports, dashboards. Per the design, members that are at least a Contributor role in the workspace will automatically have Build permissions to the workspace datasets. In addition, there are other ways of granting Build permissions. Build permission for shared datasets - Power BI | Microsoft Docs

  • Dataset owners can assign Build permission to specific users or security groups on the Manage permissions page.
  • An admin or member of the workspace where the dataset resides can decide during app publishing that users with permission for the app also get Build permission for the underlying datasets.
  • Say you have Reshare and Build permission on a dataset. When you share a report or dashboard built on that dataset, you can specify that the recipients also get Build permission for the underlying dataset.

 

If you have a clue with these design, it will make your Power BI experience better.

 

If there is any post helps, then please consider Accept it as the solution to help the other members find it more quickly. If I misunderstand your needs or you still have problems on it, please let me know. Thanks a lot!

 

Best Regards,

Community Support Team _ Caiyun

lbendlin
Super User
Super User

Pivot your thought process from Power BI structure to business needs.

Use a separate user management tool that handles onboarding/training/periodic review and expiry/offboarding.

Provide extracts of that tool (user lists) to your Power BI developers so they can use these lists in the RLS and OLS design.

for Premium capacity: Do not give access to workspaces/reports/dashboards.  Only give access to apps, and try to only give access through distribution lists. 

Helpful resources

Announcements
Join our Fabric User Panel

Join our Fabric User Panel

This is your chance to engage directly with the engineering team behind Fabric and Power BI. Share your experiences and shape the future.

June 2025 Power BI Update Carousel

Power BI Monthly Update - June 2025

Check out the June 2025 Power BI update to learn about new features.

June 2025 community update carousel

Fabric Community Update - June 2025

Find out what's new and trending in the Fabric community.