Data Security in Power BI – Users’ Roles and Permissions
In Power BI, we can store data encompassing an entire enterprise. You can create workspaces, applications and dashboards with information from individual units of the company, e.g. Controlling, Sales or Production. It is possible to establish connections with many data sources with different structures, which, following transformations, can be imported into a uniform warehouse. Data contained in Power BI may have different levels of confidentiality, which is why it is not always advisable to give all platform users full access to the content it contains. Power BI allows you to control access to data displayed on reports according to their purpose by defining the roles of users.
Security levels
Permissions are defined at three levels:
- Workspace – this is a place for storing all Power BI datasets and their related reports. Permissions at this level apply to the entire content of the workspace. The user of the service may be assigned as a manager: administrator, member or co-author. There is also a fourth group for the users who can view the content, but with no access tosettings. These are usually end users who read ready-made reports.
The chart below shows the platform with three workspaces. Understandably, depending on the license you have, there may be more of them, with more extensive content.
2. Report – Reports as such do not store data. The visualizations in them are associated with datasets which determine what portion of information may be uploaded into them. If the dataset is in a different workspace than the report, the user should be granted permissions to that dataset as well, otherwise they will only see the report in the workspace, but will not be able to use it.
This situation is presented in the chart below. The user with permissions to the sales workspace will see two reports, but will only be able to use report no. 2. To ensure that the user can access report no. 1, they should be granted permissions to the dataset located in the administration workspace.
3. Dataset – the workspace may contain information that should not be fully available to individual users. Power Bi allows you to restrict data access by setting row-level security and assigning roles to users. This is a customisable process, with the designer deciding about the number and scope of those roles.
The chart below shows how row-level security works. Both user no. 1 (sales manager) and user no. 2 (sales region south leader) have access to the sales workspace. The manager can see information for all sales areas. By applying row-level security, in the report the leader will only see data for their region, even though they use the same report as the manager.
Row-level security – an example of role usage
We will use sample country-wide sales data to demonstrate how the security mechanism works. Currently, the report displays results for all sales regions. Let’s assume that this level of detail is reserved for management, who should have access to full information. In turn, region leaders may want to see statistics related only to their own respective areas of responsibility.
To limit the amount of data displayed for the leader responsible only for a selected sales region, row-level security can be applied by configuring dataset roles in Power BI Desktop. This will prevent displaying rows that do not meet the condition specified for the selected role.
A person assigned as the south region leader will be able to display sales information only for the provinces from that region, specifically in this case: Małopolskie, Podkarpackie, Śląskie and Świętokrzyskie provinces. For each of the roles, you can assign a different a filter expression. In addition, each role can have multiple filtering expressions, e.g. it is possible to limit the data to the sales region and the current month. In this way, a user assigned to a role will see only the current data and their sales region.
To assign users to groups, you need to publish the dataset in the Power BI workspace and navigate to the row-level security management section.
From that section you can also quickly test the correct operation of security in the selected role. The reports will then be displayed in the version that the user will see, with no need to change own account permissions. You can also test the settings locally before applying them to the service in Power BI Desktop.
We should keep in mind that users assigned to row-level security roles do not have permission to manage the configuration or edit content within the entire workspace – then the restrictions for the selected data set will be overridden and they will be able to change the security settings themselves, downloading the file in full.
Summary
The discussed case presents one of the many methods of implementing the security available in Power BI. Conditions limiting the displayed data can be defined based on static conditions or using a dynamic object – for example, the name of the logged-in user.
Roles and permissions are not only security and control over access to data, but also a way to make work easier. Analyses can automatically present the business context for the person they refer to. Reports configured in this way can be further edited and extended directly in the cloud, or locally using the Power BI Desktop application, without the need to configure the data set for the end-user each time.
