Having a detailed plan for provisioning Power BI licenses and Power BI Service workspace access in your organization will help keep your deployment functioning smoothly and efficiently.Â
This blog will be helpful for anyone who is either overseeing a Power BI deployment or who already administers a Power BI Service instance.Â
In this post, we are going to discuss our recommended strategy for provisioning access to both your Power BI licenses and workspaces in Power BI Service.Â
Provisioning Licenses & Access is Easy, So Why Are We Talking About This?
Although Power BI makes granting access to data, reports, and workspaces fairly straightforward, we are going to discuss some of our recommended approaches for future proofing your Power BI deployment.Â
Provisioning access is one of those things that seems very simple at first, but almost every organization we’ve been at has had its own approach to accomplishing this task. Because of the data governance and security implications of the topic, it’s definitely a conversation worth having
How to Provision Access to Workspaces
If you are deploying Power BI to your organization for the first time, you’ll be happy to know that the Azure Active Directory (AD) groups that you have set up for access throughout your other Office applications can be used out of the box with Power BI.Â
We highly recommend using these AD groups to be the source of access so instead of granting access to content in the Power BI service, you are actually just controlling access to your workspaces through your AD group process. This will make your Power BI access process much more simple and efficient.Â
To grant access to a workspace, click on the Access icon in the top right of any workspace and you’ll see the pop-out screen as shown below. You can enter either the name of someone in your Active Directory or an Azure AD group name in the Enter email address field.Â
You then select the workspace role that the person or group will have and then click Add. If you aren’t familiar with the different roles, make sure to check out this blog by Gavin Pedersen that discusses the differences between workspaces roles.
That was easy, right? Well, it gets a little more complicated. In the example I just showed you, we had an Admin and then one group gaining access to the workspace as Members. This example is very simple and doesn’t take into account a large deployment that contains numerous workspaces and varying roles.
Larger Workspace Deployment Scenario
In the scenario where you have a lot of different workspaces with different groups taking different roles within the workspaces, the access gets a little more complicated. Our suggestion is to create different Azure AD groups for each of the roles that you anticipate users needing for each of the workspaces.Â
Take for example, a deployment of Power BI that will have five different workspaces with each workspace having needs for both Contributor and Member roles. Our suggestion would be to create a total of 10 different Active Directory groups in your Azure Portal like this:
- Workspace1-Contributor
- Workspace1-Member
- Workspace2-Contributor
- Workspace2-Member
- Workspace3-Contributor
- Workspace3-Member
- Workspace4-Contributor
- Workspace4-Member
- Workspace5-Contributor
- Workspace5-Member
Once your workspace is set up, go and grant these groups access to the workspace so that your access is then controlled through the AD group request process and not left to ad hoc requests to an actual workspace in Power BI Service.Â
For those unfamiliar with creating AD groups, go to your Azure Portal and select the Azure Active Directory application. Next, select groups and then New Group in the top left.Â
Exceptions to This Access Process
Testing Workspaces
During UAT, your testing group may be very ad hoc and smaller in number. In this instance, you can grant access to a report without granting access to the underlying data by granting testers Direct Access to the report itself.Â
You can do this by clicking on the vertical ellipses next to a report in a workspace and then clicking Manage Permissions. Select Direct Access and then Add User to allow testers access to the appropriate report.
Access is Controlled Via Workspace App
This scenario is less of an exception than a deviation from the scenario discussed in the previous section. If you are wanting to grant access to just the App (which is a best practice for viewers that we recommend) then you will grant access to the viewer AD group in the App instead of the workspace.Â
This ensures that the end viewers are only seeing the final product in the App instead of the workspace itself. Make sure to check out this blog if you are unfamiliar with workspace Apps.
Dev Workspaces
Although we still highly recommend creating an AD group for developers that will have access to the Dev workspaces, you may only want to create one group for Dev access since it will be a select group that is actually developing the content for publishing.Â
If your organization or group of developers is small enough, your Power BI admin may want to grant access to Dev workspaces on an individual basis. This is understandable due to the flexibility and quickness that it provides the Admin to control who has access to the Dev workspace.
How to Provision Licenses
Although slightly different from granting access to workspaces, at phData we recommend setting up Azure Active Directory groups for group-based license provisioning assuming that your Power BI deployment is large enough to justify it. Just like with workspaces, having an AD group that grants you a Power BI license based upon your inclusion in the AD group streamlines the process of obtaining a license into the AD process.Â
To set up your group based licensing, first make sure that you have the appropriate AD group set up first. You want the AD group name to indicate the license type and any other breakdown in the licensing that your organization may have (team, region, organization, etc.).Â
Now go to your Azure Portal and select the Azure Active Directory application and select Licenses from the left-hand side. Select All Products and then go down to your Power BI licenses. Remember, the licenses here will just be your license-based products, not Power BI Premium.Â
Your Power BI Premium SKUs will be shown in your Power BI Admin Portal. Select the license that you want to tie to your licensing AD group and then select Licensed Groups on the left-hand side. To add a group to this license select the Assign button in the top left and then add the appropriate group.Â
Now, when users are granted access to the licensing AD group, they will be granted the licenses based upon this group based licensing.Â
Closing
By following these processes you not only make your Power BI instance more organized and efficient, but you also place the burden of governance and security on your Azure Active Directory group provisioning process, which is where it should be.Â
We hope this blog made granting access and provisioning licenses a little easier to understand for you and your organization. As always, these recommendations are not one size fits all, but we have seen them help some of our clients in their Power BI deployment journeys.Â
If this blog resonated with you or if you’re interested in finding out more about the Power Platform services that we offer at phData, make sure to reach out! Our experienced and highly talented Power Platform team is here to help you with any of your problems or needs related to the Power Platform.
