Post last updated: December 11, 2021
The Power BI administrator role is a high-privilege role which should be carefully managed. As with many aspects of administration and governance, this involves having a balance between people being able to get things done and risk of when too many people having elevated permissions.
In this post (& video) we're going to cover:
Two ways we can manage membership in the Power BI Administrator role (including a new feature that was released in August 2020)
How to delegate who manages your Power BI administrators (which can be very helpful for companies where Power BI is not managed within central IT)
Groups you might need to manage Power BI effectively
How to reduce the number of full-time Power BI administrators which are assigned (without giving up the ability for people to get things done)
Do you prefer a video or reading text? I’ve got you covered with both below. The video includes demos beyond what is covered in the text+screenshots below.
***NOT SHOWN IN THE ABOVE VIDEO: Members in the Power Platform Admin role also have full access to the Power BI admin portal, and rights to manage the Power BI service for your tenant. ***
Although I’m framing this conversation around Power BI administration, most of this information applies to any type of administrator.
Let's start with what I mean by the Power BI administrator role. This is a built-in role in Microsoft 365. The following roles have the ability to manage the Power BI Service:
Global administrator role
Power Platform administrator role
Power BI administrator role
Ways to Manage Membership in the Power BI Administrator Role
What we've been doing all along to manage Power BI administrators is to assign individuals to the M365 role. Previously, only individuals could be directly added to the role in M365.
Option 1: Assign Individuals Directly to the Role
Check the accompanying video for a short demo of how this looks in M365.
However, what if we also want to use a Power BI Administrator group? We could find a group useful for several reasons.
Tenant settings. The tenant settings themselves (in the Power BI Service) require group assignments.
Workspace access. There's also managing workspace access itself--for instance, perhaps you have a set of reports related to the Power BI activity log data.
Alerting. Finally, you may also have automation jobs or alerting from Cloud App Security or M365 or PowerShell. (See this post for one situation.)
At this point we have established that I need the role, and I also have valid uses for a group. What I want to avoid is maintaining the role membership and the group membership separately. I don't like double maintenance, nor do I like the risk if and when they get out of sync.
Option 2: Assign Individuals to a Group that’s Assigned to the Role
Enter a new feature, released to preview August 2020, which allows us to assign a group to an Azure AD role. This allows us to use our Power BI Administrators group and assign it to the built-in Power BI role. Then members are assigned to the group, and not directly to the role.
Check the accompanying video for a short demo of how this looks in Azure AD.
Since this is a new feature, we do need to call out some things you need to know about.
As of when I'm writing this, it's in public preview.
It currently works for cloud (Azure AD) groups & built-in roles only. On-premises groups and custom roles are not yet supported (though they will be so check when you are watching this later).
You will need to create a brand new cloud group to make this work. The ability to align a role with a group is very powerful, and the goal is to make sure this is done very purposefully without accidental consequences.
There is no nesting of group memberships after it’s been assigned to a role.
It requires an Azure AD Premium P1 license.
It does *not* work with a mail-enabled security group. This last item is really important for managing Power BI, as we’ll see in a few moments.
Delegating Who Manages Power BI Administrators
The biggest benefit to option two above is that by aligning the role and the group we reduce maintenance and risk of inconsistencies. However, there’s another really big benefit as well.
Another benefit of aligning the role and the group is that it allows us to delegate the management of who is a member of the Power BI Administrator role to the group owner.
Let's say Power BI administration is handled by a BI team, or a Center of Excellence team, which is not part of central IT. Since we can assign a group owner -- for instance, someone from the BI or COE team -- we can now effectively delegate administration of the role.
Essentially the group owner can take the load off of your global administrator or your privileged access administrator. This can be a very big advantage in decentralized organizations.
Groups You Might Need to Manage Power BI Effectively
There are a few types of groups you're likely to have when managing Power BI (excluding groups needed in the tenant settings to grant or deny access to specific features).
Power BI Administrators. The top one shown in the image above is the group we've been discussing, which aligns to the built-in administrator role (assuming you’ve chosen to use option 2).
Power BI Admin Alerting. The second group shown in the image above relates to notifications and alerting. Specifically, the tenant setting about incidents and alerts requires a mail-enabled security group. We can’t use a mail-enabled security group if we’re going to align the group and the role (a limitation of using option 2). And, a M365 group (aka Office group or unified group) which has an e-mail address doesn't work for the incidents/alerts tenant setting in the Power BI Service. So, the trade-off I'm currently proposing is that we centralize as much as we can into the main Power BI administrator group, and maintain a second group for notification/alerting needs. (When I said earlier that option 1 doesn’t work with a mail-enabled security group, and there are implications for managing Power BI, this is what I meant.)
Power BI Gateway Admin, Power BI Capacity Admin, Power BI Support. You might be able to consolidate some or all of the last 3 groups which are shown above depending on how big you are, how many people are involved, and/or how much flexibility you want in managing your groups going forward.
How to Reduce the Number of Full-Time Power BI Administrators
Let's return for a moment to the original question: who is allowed to be an administrator? If you are in a highly decentralized organization, keeping this number low can be challenging.
There is no reader role for the Power BI administrator -- which means a highly capable Power BI champion/power user within an individual department cannot even view what the tenant settings currently look like. (This is why I always suggest that tenant settings are documented for the broader Power BI community to refer to, including what group to request access to to perform certain capabilities.)
Let's say you have a legitimate need for someone to have Power BI administrative access temporarily. They just don't need to permanently be a Power BI administrator. This is where a feature of Azure Active Directory called Privileged Identity Management (or PIM) comes in.
How PIM works:
The Azure AD administrator configures PIM.
An eligible member requests to activate their membership in the Power BI Administrator role. The eligible member is prompted for a reason why they are making the request.
Optionally, approval for the eligible member to be added to the Power BI Administrator role can be required. Or if you don't want the delay of waiting for approval, the changes will all still be logged to the audit history.
The eligible member becomes a (regular) member of the Power BI Administrator role, and can proceed with whatever needs to get done. For instance, reviewing or updating a tenant setting.
At the end of the PIM expiration time, the member is removed from the Power BI Administrator role. They are reverted back to an eligible member, so they can re-request temporary access again in the future.
Check the accompanying video for a short demo of PIM.
PIM provides a nice workflow because:
It removes the risk of having too many people with permanent, full-time, elevated permissions. Instead, it’s just-in-time access which is time-bound. You also have auditing history, approvals, and access reviews.
It lessens the need to create a secondary “admin” account that you log in with when you need the elevated permissions.
Can be used regardless of which way you manage your Power BI administrator role (assigning users directly to the role as we talked about in option 1 earlier, or using the new group membership which aligns with the role as discussed in option 2).
Using PIM is not convenient for people who are your full-time Power BI administrators, especially if you use the same Power BI admin group (tied to the Power BI admin role if using option 2) for regular workspace security.
Also, note that PIM requires an Azure AD Premium P2 license.
That’s it! There are certainly a few different ways to handle which groups you need, and how to manage membership in the Power BI Administrator role. I hope this post gave you some ideas for being efficient while also reducing risk.
Where Can You Find More Information?
Assigning groups to Azure AD roles is now in public preview
Use cloud groups to manage role assignments in Azure Active Directory
FAQs and troubleshooting roles assigned to cloud groups
What is Azure AD Privileged Identity Management?
License requirements to use Privileged Identity Management
Management capabilities for privileged access Azure AD groups
Understanding Power BI service administrator roles
Administering Power BI in the admin portal
Service administrator permission matrix
Like this Content?
Take a look at our Power BI Deployment & Governance training course. The course includes a template for documenting your tenant settings, which is really helpful for your internal community of users.
