Understanding the details behind all the different roles and access controls you can have when governing your Power BI content can be a bit confusing sometimes.
I often struggle to remember what tenant settings can I use to restrict users from publishing content, the different roles users can have in workspaces and what they can and can't do in each one of those roles.
To make our life easier, I will try to summarise in an easy way how you can restrict users from publishing and accessing content.
Some of you might have heard of the "least privilege principle". Even though I don't necessarily agree with restricting users too much as this can make them frustrated and impact the adoption of new technology, often we need to restrict what users can and can't do in our environment a little bit.
Principle of least privilege:
"The principle means giving a user account or process only those privileges which are essential to perform its intended function. For example, a user account for the sole purpose of creating backups does not need to install software: hence, it has rights only to run backup and backup-related applications. Any other privileges, such as installing new software, are blocked."
Based on the principle of least privilege, you need to think what works and doesn't work in your own business environment. This is not a one size fits all thing, you need to think carefully about the different roles your users will have, and define governance processes that will best serve them and keep your environment healthy.
In one of my previous blog posts, I wrote about My views on Power BI core skills (datapears.com).
So, looking at the pyramid, the processes you use to restrict content creation and sharing in your organisation falls under the "Governance & Admin" corner.
This means that, specially if you have a lot of users creating reports, you should probably have someone responsible for looking into the governance processes of your enterprise Power BI environment. It's not enough to define processes and guidelines though, you need to work with the users and help them on their journey by guiding them on how the environment works, how it's managed etc.
Again, I've seen use cases where a lot of Power BI features were restricted or blocked, and the effects this would have on the users were poorly accessed. The users would often feel like they couldn't do anything without "asking for permission", leading to poor/low adoption. You could end up with a tool that could be excellent, but if users don't understand why you're restricting them, the processes involved etc, the tool ends up not being used as it should.
This "intro" was just to make sure you understand that you shouldn't use this blog post without looking carefully at your own environment/business and your users expectations and needs.
So, having this, let's finally start talking about how you can restrict content creation and sharing!
You can usually restrict content creation/sharing at either:
> Tenant level
> Workspace level
> Report Level
As you can see from the image on the right, the different levels go from the most restrictive - Tenant level, to the least restrictive - Report level.
This means that, if you apply any restrictions on the tenant level, these restrictions will be applied to all workspaces on that tenant.
The same goes for the workspace restrictions, if you apply restrictions at this level, they will be propagated to all the reports on that level.
This leaves the report level restrictions as the least granular level, where these will only be applied to the specific report you choose to apply the restrictions to.
Tenant Level Restrictions
There are four sections in the Power BI Admin portal you should look at if you want to restrict users from creating and sharing content in Power BI:
> Workspace settings
Create workspaces (new workspace experience)
Use datasets across workspaces
> Export and sharing settings
Allow Azure Active Directory guest users to access Power BI
Invite external users to your organization
Allow Azure Active Directory guest users to edit and manage content in the organization
Show Azure Active Directory guests in lists of suggested people
Publish to web
Export to Excel
Export to .csv
Download reports
Export reports as PowerPoint presentations or PDF documents
Export reports as MHTML documents
Export reports as Word documents
Export reports as XML documents
Export reports as image files (Preview)
Print dashboards and reports
Email Subscriptions *
Allow connections to featured tables
Allow shareable links to grant access to everyone in your organization
> Integration settings
Allow XMLA endpoints and Analyze in Excel with on-premises datasets
> Dataflows settings
Create and use dataflows *
* These features work only on an ON/OFF basis for the entire tenant, no option to allow these features for only specific security groups. The features signalled without the * can be applied to specific security groups only.
As you can see, the options are almost infinite (specially with the Export and Sharing settings)!
For me, one of the most important features from this list is "Create workspaces". The reason I say this is because if you don't restrict the workspace creation, then every user will be able to create workspaces. This can lead to a proliferation of workspaces, datasets, you can end up with thousands of workspaces that are rarely used or duplicated, and that are filling up your capacity.
As we will see in the workspace level restrictions section, if users can freely create their workspaces, as creators they will automatically be admins of that workspace, meaning they can give access to any user in the organisation, to any content he/she creates. So, applying restrictions at workspace level without thinking about applying some restrictions or control methods at the tenant level will probably not work out very well.
The good thing is, you can restrict the workspace creation to a group of users. So you can define who in your organisation can create workspaces, train them on how they should create workspaces, the governance processes, and facilitate the process for everyone.
But, as with everything, limiting the governance to only restricting users from creating workspaces is usually not enough. You can still end up with workspaces that are never used, but are filling up your capacity. So it's also very important to regularly check your tenant workspaces usage metrics, to see if the workspaces/reports/datasets are actually being used, and take actions if not.
Regularly checking the usage metrics of my tenant/capacity and build my governance processes around that would ideally be my preferred method, instead of just blocking features to users. This way, you can create governance rules based on your usage metrics such as:
> If a workspace has not been used for more than 12 months, send a warning to the admins saying this workspace will be removed and the content archived in a storage of your choice.
> If no action is taken from the workspace admin, remove the workspace, archive the reports.
This way, you can educate the user that he/she needs to keep their workspaces clean, without necessarily restricting them.
Workspace level restrictions
As I mentioned before, if you really want to apply the principle of least privilege and for some reason you need to restrict what users can and can't do in your tenant, you definitely need to think about the tenant level restrictions before you get to the workspace level restrictions.
But, as we already discussed the tenant level restrictions, let's move on to workspaces.
When looking at restrictions at workspace level, you need to think about the different roles users can have in workspaces:
> Admin
> Member
> Contributor
> Viewer
This list goes from the most privileged role - Admin, to the least privileged role - Viewer.
If you want to check what's allowed with each one of the roles, this table will give you a very detailed overview:
But, as you go through the table, you probably find yourself thinking "ok..... but just give me the the juice of that table, what can I do to restrict users from creating or deleting content in a workspace??". The easy answer is: give them a Viewer role.
With the Viewer role, the only actions users can do are: view and interact with content in the workspace. All the other roles will give users access to delete and create content in that workspace (reports, datasets and dataflows).
One of the easiest ways to attribute roles to users is by using security groups instead of giving them access manually one by one. Don't know how to do it? Here are a few link (this is probably IT managed, but good to know how it works anyway):
If you go for the security groups option, here is a suggestion for groups you could use in your governance solution:
> Power BI Admin: Workspace Admin role - manages the workspace
> Power BI Contributor: Workspace Member role - creates and removes content from the workspace
> Power BI Viewer: Workspace Viewer role - end user, who doesn't create content, only consumes reports
You can check who has access to the workspace and their role here:
You can also change the roles for individual groups or security groups in the Access Settings.
Report/Dataset level restrictions
Lastly, you can also restrict the access to the content in your workspace at the report/dataset level.
When you publish a report to Power BI Service, you are also publishing a dataset. To restrict users from using this dataset, you need to look at the Build permissions for that dataset.
Build permissions allow users to:
> Build new content using the dataset
> Export the underlying data
> Access the data using the XMLA endpoint
> Use Analyse in Excel
When you're sharing your report with others, you can choose to give them build permissions:
If you untick the "Allow recipients to build content with the data associated with this report", you're removing the build permissions for the users you're sharing your report with.
Remember that this will only work for users with a Viewer role in that workspace, if the user has any other role (Contributor, Member, Admin) even if you remove the build permissions to that user, he will still be able to use the dataset because he has a higher level of privilege in the workspace that allows him to use any dataset in that workspace.
If you want to check which users have build permissions, you can do that by going to the Datasets + dataflows tab of the workspace, click on the "...", and then on "Manage permissions":
You can then remove or add access to the users from the list:
Read more about build permissions here:
Using Apps
If you're using Power BI Apps to distribute your content, you can also restrict users from using the underlying data:
To restrict users from using or sharing the underlying datasets of the app, you just need to disable the options "Allow all users to connect to the app's underlying datasets using Build permission." and "Allow users to share the app and the app's underlying datasets using the share permission".
In this case, there is no option to enable or disable these options for a specific group of users, meaning that you either enable or disable these options to everyone who has access to the app.
When using Apps to distribute your content, your end users shouldn't have access to the workspace, so you should give users access only to the App, and not to the workspace (not even Viewer role!).
Summary
To restrict users from creating workspaces and content in those workspaces you need to:
Look at the Tenant level permissions on the Admin portal: you need to restrict who can create workspaces in your tenant to a group of users (preferably using an AD security group).
Look at the workspace level permissions: Your end users should have only Viewer role in the workspace.
Look at the report level permissions: You should give dataset build permissions only to the group of users you want to be able to work with the dataset.
Look at the App permissions: You should enable/disable the options for sharing and using underlying datasets in the App when publishing it.
Interested in learning more about Power BI Report Design? Then the Power BI Report Design Bootcamp is for you!
