Training
Learning path
Implement finance and operations apps - Training
Plan and design your project methodology to successfully implement finance and operations apps with FastTrack services, data management and more.
This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
Note
This article forms part of the Power BI implementation planning series of articles. This series focuses primarily on the Power BI experience within Microsoft Fabric. For an introduction to the series, see Power BI implementation planning.
This security planning article describes strategies for read-only consumers. The focus is on viewer permissions for reports and apps, and how to enforce data security. It's primarily targeted at:
The series of articles is intended to expand upon the content in the Power BI security white paper. While the Power BI security white paper focuses on key technical topics such as authentication, data residency, and network isolation, the primary goal of the series is to provide you with considerations and decisions to help you plan for security and privacy.
In an organization, many users are classified as consumers. Consumers view content that other users have created and published. Consumers are the focus of this article. For security planning focused on content creators and owners, see the Content creator security planning article.
To get the most from this article, it's helpful to understand the meaning of the terms sharing and distribution in the context of Power BI.
Sharing is where one user gives another user (or group of users) access to a specific item of content. The sharing capability in the Power BI service is scoped to one item. It most commonly takes place between individuals who know each other and work closely together.
Distribution is where content is delivered to other users, who are known as recipients. It often involves a larger number of users across multiple teams. Recipients might not have explicitly requested the content, but it's recognized that they need it to perform their role. Recipients who consume distributed content might or might not know the original creator of the content. As such, distribution as a concept is more formal than sharing.
When you talk with other people, determine whether they're using the term sharing in a general way, or literally. Use of the term sharing can be interpreted in two ways.
Important
The Power BI administrator role has been renamed. The new name of the role is Fabric administrator.
In the Power BI service, consumers can view a report or dashboard when they have permission to both:
You can provide read-only access to consumers by using different techniques. The common techniques used by self-service content creators include:
The Power BI app and Power BI workspace Viewer role options involve managing permissions for a set of items. The two per-item permissions techniques involve managing permissions for one individual item.
Tip
Generally, it's a best practice to use a Power BI app for most consumers. Occasionally the workspace Viewer role could also be appropriate. Both Power BI apps and the workspace Viewer role allow managing permissions for many items, and should be used whenever possible. Managing permissions for individual items can be tedious, time consuming, and error prone. In contrast, managing a set of items reduces maintenance and improves accuracy.
When reviewing security settings for an item, you might see that its permissions are either:
In the following screenshot, the Direct access permissions are shown for a report. In this instance, the workspace Admin and Member roles are each assigned to a group. These roles are shown for the report because the report-level access is inherited from the workspace. There's also one user who has Read permissions applied directly to the report.
The strategy you choose for read-only consumers can be different. It should be based on the individual solution, the preferences of who manages the solution, or the needs of the consumer. The remainder of this section describes when to consider using each of the available techniques.
Checklist - When creating your strategy for how to provide content to read-only consumers, key decisions and actions include:
A Power BI app delivers a collection of reports, dashboards, and workbooks to consumers. An app provides the best user experience for consumers because:
Note
All references to an app in this article refer to a Power BI app. It's a different concept from Power Apps. It's also a different concept than the Power BI mobile applications. In this section, the focus is on organizational apps rather than template apps.
You can create one app for each workspace as a formal way to distribute some, or all, workspace content. Apps are a good way to distribute content broadly within an organization, especially to users that you don't know or don't collaborate with closely.
Tip
For more information about using a Power BI app for broad content distribution, see the enterprise BI usage scenario. We recommend that content creators who need to distribute content consider creating an app as their first choice.
You manage app permissions separately from workspace roles. The separation of permissions has two advantages. It encourages:
All users with workspace access can automatically view the app (when a Power BI app has been published for the workspace). Due to this behavior, you can conceptually think of workspace roles as being inherited by each app audience. Some users with workspace access can also update the Power BI app, depending on their assigned workspace role.
Tip
For more information about workspace access, see the Content creator security planning article.
Using an app to distribute content to read-only consumers is the best choice when:
While it's true that changes to reports and dashboards aren't visible to users of the app until the app is republished, there are two considerations that require caution.
Each workspace in the Power BI service can have only one Power BI app. However, within the app you can create one or more audiences. Consider the following scenario.
This capability to mix and match content and audiences has the following advantages.
The following screenshot shows an app with two audiences: Sales Leadership and Sales Reps. The Manage Audience Access pane provides access to the Sales Leadership audience group for two security groups: Sales Leadership-North America and Sales Leadership-Europe. The Gross Margin Analysis report that's shown in the screenshot for the Sales Leadership audience group isn't available to the Sales Reps audience group.
Note
The term audience group is sometimes used. It isn't a direct reference to the use of security groups. It includes members of the target audience who will see the collection of content within a Power BI app. While you can assign individual users to an audience, it's a best practice to assign security groups, Microsoft 365 groups, or distribution groups whenever practical. For more information, see the strategy for using groups in the Tenant-level security planning article.
When you manage permissions for an app, on the Direct Access page you can view the members of each audience. You can also see users with a workspace role listed under the All audience. You can't update the app permissions from the Direct Access page. Instead, you must republish the app. You can, however, update app permissions from the Pending page when there are open access requests for the app.
Tip
The primary use case for using app audiences is to define specific permissions for different sets of users. However, you can get a little creative when using audiences. A user can be a member of multiple audiences, and each audience is shown to viewers of the app as a secondary set of menus. For example, you can create an audience named Start Here that contains information about how to use the app, who to contact, how to provide feedback, and how to get help. Or, you can create an audience named KPI Definitions that includes a data dictionary. Providing this type of information helps new users and improves solution adoption efforts.
When you create (or republish) an app, each audience has a Manage Audience Access pane. In that pane, the following permissions are available.
The capability to add the semantic model Reshare or Build permissions while publishing an app is convenient. However, we recommend that you consider managing app permissions and semantic model permissions separately. Here are the reasons why.
Tip
For more information about when to use separate data workspaces and reporting workspaces, see the Workspace-level planning article.
After you publish a Power BI app, a user typically needs to install it so they can open it. A user can install an app from the Apps page in the Power BI service, or by using a link they've received from another user. They'll be able to find (and install) an app when they're included in at least one audience of the app.
An alternative approach to install an app is to push it to app consumers. It results in the pre-installation of the app so that it automatically shows up in the Apps page in the Power BI service. This approach is a convenience for consumers because they don't need to find and install the app. However, pre-installed apps can become an annoyance for users because they might become overwhelmed by too many apps that aren't relevant to them.
The Push apps to end users tenant setting controls who's allowed to automatically install apps. We recommend that you use this feature because it's convenient for users. However, we also recommend that you educate your content creators on when to use it so that it isn't overused.
Tip
When publishing an app, if you select the option to install the app automatically, you can't set the audience to be the entire organization (if enabled by the Push apps to end users tenant setting).
Checklist - When creating your strategy for using apps for content viewers, key decisions and actions include:
As described in the Workspace planning articles, the primary purpose of a workspace is collaboration. Workspace collaborators, such as semantic model creators, report creators, and testers, should be assigned to one of three roles: Contributor, Member, or Admin. These roles are described in the Content creator security planning article.
You can assign the workspace Viewer role to consumers. Allowing consumers to access content directly in a workspace can make sense for small teams and informal teams who work closely together.
Allowing consumers to access workspace content directly is a good choice when:
Here are some suggestions to support workspace viewers.
Checklist - When creating your strategy for using workspaces for content viewers, key decisions and actions include:
Individual item sharing grants permission to a single item. Less experienced content creators commonly use this technique as the primary sharing technique because the sharing commands are prominently displayed in the Power BI service. For this reason, it's important to educate your content creators on the different sharing options, including when to use app permissions instead of workspace roles.
Per-item permissions are a good choice when:
Use per-item permissions sparingly because sharing grants Read permission to a single item. In a way, you can think of per-item permissions as an override of workspace roles or app permissions.
Tip
We recommend that you use app permissions whenever possible. Next, consider using workspace roles to enable direct workspace access. Lastly, use per-item permissions when they meet the above criteria. App permissions and workspace roles both specify security for a collection of content (rather than individual items), which is a better security practice.
Sharing many items by using per-item permissions can be tedious and error prone, especially when sharing to individual users instead of groups. Consider this scenario: You have 40 reports that you've shared to colleagues by using their individual user accounts. When one colleague transfers to a different department, you'll need to revoke their access, which will involve editing permissions for all 40 reports.
Important
Sharing content from a personal workspace should be done infrequently. Personal workspaces are best suited to non-critical, informal, or temporary content. If you have a situation where content creators frequently share important or critical content from their personal workspaces, you should take appropriate action to move that content to a standard workspace. For more information, see the personal BI usage scenario.
When you share an individual item, you have several permission options.
Per-item permissions for reports and dashboards can make sense for informal scenarios when content is shared with a few users. It's a good idea to educate users on managing permissions with apps and workspaces instead, especially when they're sharing content to large numbers of users or users outside their team. It's important to emphasize the following points.
There are three specific types of sharing: sharing links, direct access sharing, and shared views.
When you share an individual item, the default experience results in a sharing link. There are three types of sharing links.
Important
We recommend that you consider restricting the Allow shareable links to grant access to everyone in your organization tenant setting to members of a group. You can create a group name like Power BI Share to Entire Organization, and then add a small number of users who understand the implications of organization-wide sharing. If you're concerned about existing organization-wide links, you can use the admin API to find all items that have been shared with the entire organization.
A sharing link adds Read permission to the item. The Reshare permission is selected by default. It's also possible to add Build permission to the underlying semantic model at the same time that the sharing link is created.
Tip
We recommend that you teach content creators to enable the Build permission option only when the consumer of the report is also a content creator who might need to create reports, export data, or create a composite model from the underlying semantic model.
Sharing links are easier to maintain than direct access sharing, particularly when you need to do bulk changes. It's a significant advantage when individual users are granted sharing permissions, more so than groups (which commonly occurs when self-service users are responsible for managing permissions). Consider the following comparisons.
You can also achieve per-item permissions by using direct access. Direct access involves setting up the permissions for a single item. You can also determine any inherited permissions derived from workspace roles.
When you grant a user direct access, they're granted Read permission for the item. The Reshare permission is selected by default, as is the Build permission for the underlying semantic model. We recommend that you teach content creators to enable Build permission only when the consumer of this report is also a content creator who might need to create reports, export data, or create composite models from the underlying semantic model.
Tip
The user experience makes granting Reshare and Build permissions very straightforward, but the user doing the sharing should always verify whether those permissions are necessary.
Use a shared view to share a filtered perspective of a report with another user. You can publish a shared view by using a sharing link or by direct access.
Shared views are a temporary concept. They automatically expire after 180 days. For this reason, shared views are best suited to informal and temporary sharing scenarios. Be sure your users are aware of this limitation.
Checklist - When creating your strategy for using per-item permissions, key decisions and actions include:
The most common ways for consumers to interact with Power BI are with apps, workspaces, and per-item permissions (previously described in this article).
There are other techniques that consumers can use to query Power BI data. Each of the following query techniques requires semantic model or datamart Build permission.
For more information about the Build permission, see the Content creator security planning article.
Checklist - When planning which query techniques consumers will use, key decisions and actions include:
When sharing content, it's common that one user forwards a link (URL) to another user. When the recipient tries to view the content, and discovers that they don't have access to it, they can select the Request access button. This action initiates the Request access workflow. The user is then asked to provide a message to explain why they want access.
A Request access workflow exists for:
There are two ways to learn about pending access requests that have been submitted for an app.
Pending access requests for an app show the message provided by the user. Each pending request can be approved or declined. When choosing to approve a request, an app audience must be selected.
The following screenshot shows a pending access request from a user. To approve it, one of the two app audiences, Sales Reps or Sales Leadership, must be selected.
When you publish an app, the content and the permissions are published at the same time. As previously described, it's not possible to publish only the app permissions without content changes too. However, there's one exception: When you approve a pending access request (such as the one shown in the previous screenshot), the permission change occurs without publishing the latest content in the workspace.
Workspace access is granted by users who belong to the Admin role or Member role.
A user who is attempting to view a workspace receives an access denied message when they aren't a member of a workspace role. Since there isn't a built-in Request access workflow for workspaces, they're best used for small teams and informal teams who work closely together. That's one reason why a Power BI app is better suited to larger teams and broader content distribution scenarios.
There are two ways to learn about pending access requests that have been submitted for an individual item, like a report.
When a user submits the Request access form for a Power BI item (like a report or semantic model) or a Power BI app, the request is submitted for an individual user. However, many large organizations need to use groups to comply with their internal security policies.
We recommend that you use groups, rather than individuals, for securing content whenever practical. For more information about planning for groups, see the Tenant-level security planning article.
If you intend to provide access to groups instead of individual users, the content owner or administrator that's processing the request for access will need to complete the request in multiple steps:
Tip
See Request access workflow for creators for information about responding to requests for Build access from content creators. It also includes recommendations about using a form for access requests.
Checklist - When planning the Request access workflow, key decisions and actions include:
You can plan to create fewer semantic models and reports by enforcing data security. The objective is to enforce data security based on the identity of the user who's viewing the content.
For example, consider that you can share a single sales report with all salespeople (consumers), knowing that each salesperson will only see sales results for their region. This approach allows you to avoid the complexity of creating separate reports per region that would need to be shared with the salespeople from that sales region.
Some organizations have specific requirements for endorsed (certified or promoted) semantic models or datamarts. For data that will be widely used, there might be a requirement to use data security.
You can accomplish data security in multiple ways.
Note
Source systems, like Azure SQL Database, can also use techniques like views to narrow down what the user can see. While that's a valid technique, it's not relevant to the focus of this section.
Row-level security (RLS) allows a data modeler to restrict access to a subset of data. It's typically used to ensure that some report consumers can't see specific data, like sales results of other sales regions.
Tip
If you've noticed someone creating multiple data models to support different groups of consumers, check whether RLS will satisfy their requirements. It's typically better to create, test, and maintain one data model rather than multiple data models.
Take care, because if a Power BI report references a row with RLS configured then the same message will be displayed as for a deleted or non-existing field. To these users, it looks like the report is broken.
There are two steps for setting up RLS: rules and role mappings.
For semantic models, a data modeler can set up RLS in Power BI Desktop by creating one or more roles. A role has a unique name in the model, and it usually includes one or more rules. Rules enforce filters on model tables by using Data Analysis Expressions (DAX) filter expressions. By default, a model has no roles.
Important
A model without roles means that users (who have permission to query the data model) have access to all model data.
Rule expressions are evaluated within row context. Row context means the expression is evaluated for each row by using the column values of that row. When the expression returns TRUE
, the user can see the row. You can define rules that are either static or dynamic.
[Region] = "Midwest"
.After you publish the model to the Power BI service, you must set up role mappings in advance of users accessing related reports. Role mapping involves assigning Microsoft Entra security objects to roles. Security objects can be user accounts or security groups.
Whenever possible, it's a best practice to map roles to security groups. That way, there will be fewer mappings, and group membership management can be handled by the owner of the group.
We recommend that you make security account information from Microsoft Entra available to your content creators. One option is to create a dataflow with data that's kept in sync with Microsoft Entra ID. That way, content creators can integrate the dataflow data to produce a data-driven semantic model.
Tip
It's possible to define a role that has no rules. In this case, the role provides access to all rows of all model tables. Setting up this type of role is suitable when an administrator or user is allowed to view all data in the model.
Some organizations choose to purposefully use RLS as a secondary layer of security, in addition to standard Power BI permissions. Consider the following scenario: You share a link to a report with the entire organization. Any user who views the report must be mapped to an RLS role to be able to see data in the report. If they aren't mapped to an RLS role, they won't see any data.
The presence of RLS changes the default experience for consumers.
Note
Some organizations enforce RLS as an additional layer of security, especially when sensitive data is involved. For this reason, you might choose to require RLS for semantic models that are certified. That requirement can be accomplished with an internal review and approval process prior to certifying the semantic model.
When a user views a report in either a workspace or an app, RLS might or might not be enforced depending on their semantic model permissions. For this reason, it's critical that content consumers and creators only possess Read permission on the underlying semantic model when RLS must be enforced.
Here are the permission rules that determine whether RLS is enforced.
Tip
For more information about how to use separate workspaces so that RLS works for content creators, see the managed self-service BI usage scenario.
For more information about RLS, see Restrict access to Power BI model data.
Power BI datamarts can also enforce RLS. However, the implementation is different.
The main difference is that RLS for datamarts is set up in the Power BI service, rather than in Power BI Desktop.
Another difference is that datamarts enforce RLS on both the semantic model and the managed Azure SQL Database that's associated with the datamart. Enforcing RLS at both layers provides consistency and flexibility. The same RLS filters are applied regardless of how the user queries the data, whether it's by connecting to the semantic model or to the managed Azure SQL Database.
For more information, see RLS for datamarts.
Object-level security (OLS) allows a data modeler to restrict access to specific tables and columns, and their metadata. You typically use OLS to ensure sensitive columns, like employee salary, aren't visible to certain users. While it isn't possible to restrict access to measures, any measure that references a restricted column will itself be restricted.
Consider an example of an employee table. It contains columns that store the employee name and phone number, and also salary. You can use OLS to ensure that only certain users, like senior Human Resources staff, can see salary values. For those users that can't see salary values, it's as if that column doesn't exist.
Take care, because if a Power BI report visual includes salary, users that don't have access to that field will receive an error message. The message will inform them that the object doesn't exist. To these users, it looks like the report is broken.
Note
You can also define perspectives in a data model. A perspective defines viewable subsets of model objects to help provide a specific focus for report creators. Perspectives aren't intended to restrict access to model objects. A user can still query a table or column even when it's not visible to them. Therefore, consider perspectives as a user convenience rather than a security feature.
There isn't currently an interface in Power BI Desktop to set up OLS. You can use Tabular Editor, which is a third-party tool for creating, maintaining, and managing models. For more information, see the advanced data model management usage scenario.
For more information about OLS, see Restrict access to Power BI model objects.
Checklist - When planning for RLS and OLS, key decisions and actions include:
In the next article in this series, learn about security planning for content creators who are responsible for creating semantic models, dataflows, datamarts, reports, or dashboards.
Training
Learning path
Implement finance and operations apps - Training
Plan and design your project methodology to successfully implement finance and operations apps with FastTrack services, data management and more.