Events
Power BI DataViz World Championships
Feb 14, 4 PM - Mar 31, 4 PM
With 4 chances to enter, you could win a conference package and make it to the LIVE Grand Finale in Las Vegas
Learn moreThis 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 content creators who are responsible for creating semantic models, dataflows, datamarts, reports, or dashboards. 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 content creators. Content creators produce and publish content that's viewed by others. Content creators are the focus of this article.
Tip
We recommend that you review the Report consumer security planning article first. It describes strategies for securely providing content to read-only consumers including how to enforce data security.
The foundation of a well-governed self-service BI system begins with content creators and owners. They create and validate semantic models and reports. In many cases, content creators also set up permissions to manage security for their content.
Tip
We recommend that you foster a data culture that makes security and protection of data a normal part of everyone's role. To achieve that objective, user education, support, and training is essential.
For purposes of security and permissions, consider that there are two types of content creators: data creators and report creators. They can be responsible for creating and managing enterprise BI or self-service BI content.
A data creator is any Power BI user who creates semantic models, dataflows, or datamarts.
Here are some common data creator scenarios.
Data creators are often found in enterprise BI teams and in the Center of Excellence (COE). They also have a key role to play in decentralized business units and departments that maintain and manage their own data.
For other considerations about business-led BI, managed self-service BI, and enterprise BI, see the Content ownership and management article.
Report creators create reports and dashboards to visualize data that's sourced from existing semantic models.
Here are some common report creator scenarios.
Report creators are found throughout every business unit in the organization. There are usually many more report creators in an organization than data creators.
Tip
While not every semantic model is a shared semantic model, it's still worth adopting a managed self-service BI strategy. This strategy reuses shared semantic models whenever possible. In that way, report creation and data creation are decoupled. Any content creator from any business unit can effectively use this strategy.
This section describes the most common permissions for data creators and report creators.
This section isn't intended to be an all-inclusive list of every possible permission. Rather, it's intended to help with planning your strategy for supporting different types of content creators. Your goal should be to follow the principle of least privilege. This principle allows enough permissions for users to be productive, without over-provisioning permissions.
The following permissions are commonly required for creating new content.
Permission | Report creator | Semantic model creator | Dataflow creator | Datamart creator |
---|---|---|---|---|
Access to the underlying data source | ||||
Semantic model Read and Build permissions | ||||
Dataflow Read permission (when a dataflow is used as a source, via the workspace Viewer role) | ||||
Access where original Power BI Desktop file is stored | ||||
Permission to use custom visuals |
The following permissions are commonly required for publishing content.
Permission | Report creator | Semantic model creator | Dataflow creator | Datamart creator |
---|---|---|---|---|
Workspace role: Contributor, Member, or Admin | ||||
Semantic model Write permission (when the user doesn't belong to a workspace role) | ||||
Deployment pipeline role to publish items (optional) |
The following permissions are commonly required for refreshing data.
Permission | Report creator | Semantic model creator | Dataflow creator | Datamart creator |
---|---|---|---|---|
Owner assigned (who has set up settings or taken over the item) | ||||
Access to the underlying data source (when a gateway isn't used) | ||||
Access to the data source in a gateway (when the source is on-premises or in a virtual network) |
The remainder of this article describes considerations for content creator permissions.
Tip
For permissions related to viewing content, see the Report consumer security planning article.
Checklist - When planning your security strategy for content creators, key decisions and actions include:
Users can rely on data discovery to find semantic models and datamarts. Data discovery is a Power BI feature that allows content creators to locate existing data assets—even when they don't have any permissions for that content.
Discovery of existing data is useful for:
Note
Data discovery in Power BI isn't a data security permission. It's a setting that allows report creators to read metadata, helping them to discover data and request access to it.
You can set up a semantic model or datamart as discoverable when it's been endorsed (certified or promoted). When it's discoverable, content creators can find it in the OneLake catalog.
A content creator can also request access to the semantic model or datamart. Essentially, an access request asks for Build permission, which is required to create new content based on it. When responding to requests for access, consider using groups instead of individual users. For more information about how to use groups for this purpose, see Request access workflow for consumers.
Consider the following three examples.
The following screenshot shows a semantic model in the OneLake catalog in the Fabric portal. Specifically, it shows an example of a Request access message for a discoverable semantic model. This message is shown when the user doesn't currently have access. The Request access message has been customized in the semantic model settings.
The Request access message reads: For standard sales reporting of MTD/QTD/YTD, this semantic model is the authoritative and certified source. Please request access to the semantic model by completing the form located at https://COE.contoso.com/RequestAccess
. You will be asked for a brief business justification, and the manager of the Center of Excellence will be required to approve the request as well. Access will be audited every six months.
Note
Your data culture and your stance on data democratization should strongly influence whether you enable data discovery. For more information about data discovery, see the customizable managed self-service BI usage scenario.
There are three tenant settings related to discovery.
Checklist - When planning data discovery for your content creators, key decisions and actions include:
A user can request access to content in two ways.
By default, a request for access to a semantic model or a datamart goes to the owner. The owner is the user who last scheduled data refresh or input credentials. Relying on one user to process access requests might be acceptable for team semantic models. However, that might not be practical or reliable.
Instead of relying on one owner, you can define custom instructions that are presented to users when they request access to a semantic model or datamart. Custom instructions are helpful when:
The following screenshot shows an example of setting up custom instructions that a user sees when they request the Build permission. The custom instructions read: For standard sales reporting of MTD/QTD/YTD, this semantic model is the authoritative and certified source. Please request access to the semantic model by completing the form located at https://COE.contoso.com/RequestAccess
. You will be asked for a brief business justification, and the manager of the Center of Excellence will be required to approve the request as well. Access will be audited every six months.
There are many options to create a form. Power Apps and Microsoft Forms are both low-code, easy-to-use options. We recommend that you create a form in a way that's independent of a single user. It's crucial that your form is created, managed, and monitored by the proper team.
We recommend that you create helpful information for:
Tip
For more information about responding to requests for read access from consumers, see Request access workflow for consumers. It also includes information about using groups (instead of individual users).
Checklist - When planning the Request access workflow, key decisions and actions include:
This section includes security aspects that apply to content creators.
Note
For consumers who view reports, dashboards, and scorecards, see the Report consumer security planning article. Considerations related to app permissions are covered in that article, too.
You grant workspace access by adding users or groups (including security groups, Microsoft 365 groups, and distribution lists) to workspace roles. Assigning users to workspace roles allows you to specify what they can do with the workspace and its content.
Note
For more information about workspace planning considerations, see the workspace planning articles. For more information about groups, see the Tenant-level security planning article.
Because the primary purpose of a workspace is collaboration, workspace access is mostly relevant for the users who own and manage its content. When starting to plan for workspace roles, it's helpful to ask yourself the following questions.
There are four Power BI workspace roles: Admin, Member, Contributor, and Viewer. The first three roles are relevant to content creators, who create and publish content. The Viewer role is relevant to read-only consumers.
The four workspace role permissions are nested. That means that workspace administrators have all the capabilities available to members, contributors, and viewers. Likewise, members have all the capabilities available to contributors and viewers. Contributors have all the capabilities available to viewers.
Tip
See the workspace roles documentation for the authoritative reference for each of the four roles.
Users assigned to the Admin role become the workspace administrators. They can manage all settings and perform all actions, including adding or removing users (including other workspace administrators).
Workspace administrators can update or delete the Power BI app (if one exists). They can, optionally, allow contributors to update the app for the workspace. For more information, see Variations to workspace roles later in this article.
Tip
When referring to an administrator, be sure to clarify whether you're speaking about a workspace administrator or a Power BI tenant-level administrator.
Take care to ensure that only trusted and reliable individuals are workspace administrators. A workspace administrator has high privileges. They have access to view and manage all content in the workspace. They can add and remove users (including other administrators) to any workspace role. They can also delete the workspace.
We recommend that there are at least two administrators so that one serves as a backup should the primary administrator be unavailable. A workspace that doesn't have an administrator is known as an orphaned workspace. The orphaned status occurs when a user leaves the organization and there's no alternative administrator assigned to the workspace. For more information about how to detect and rectify orphaned workspaces, see Manage workspaces.
Ideally, you should be able to determine who's responsible for the workspace content by who the workspace administrators and members are (and the contacts specified for the workspace). However, some organizations adopt a content ownership and management strategy that restricts workspace creation to specific users or groups. They typically have an established workspace creation process that is managed by the IT department. In this case, the workspace administrators would be the IT department rather than the users who directly create and publish the content.
Users assigned to the Member role can add other workspace users (but not administrators). They can also manage permissions for all content in the workspace.
Workspace members can publish or unpublish the app for the workspace, share a workspace item or the app, and allow other users to share workspace items of the app.
Workspace members should be limited to the users who need to manage the workspace content creation and publish the app. In some cases, the workspace administrators fulfill that purpose, so you might not need to assign any users or groups to the Member role. When the workspace administrators aren't directly related to the workspace content (for example, because IT manages the workspace creation process), the workspace members might be the true owners responsible for the workspace content.
Users assigned to the Contributor role can create, edit, or delete workspace content.
Contributors can't update the Power BI app (when one exists for the workspace) unless that's been allowed by the workspace setting. For more information, see Variations to workspace roles later in this article.
Most content creators in the organization are workspace contributors.
Users assigned to the Viewer role can view and interact with all workspace content.
The Viewer role is relevant to read-only consumers for small teams and informal scenarios. It's fully described in the Report consumer security planning article.
Consider an example where the following actions are taken to set up a new workspace.
The previous example shows an effective way to allow a decentralized business unit the ability to act independently. It also shows the principle of least privilege.
For governed content, or critical content that's more tightly managed, it's a best practice to assign groups rather than individual user accounts to workspace roles. That way, you can manage the group membership separately from the workspace. However, when you assign groups to roles, it's possible that users become assigned to multiple workspace roles (because the user belongs to multiple groups). In that case, their effective permissions are based on the highest role that they're assigned to. For more considerations, see Strategy for using groups.
When a workspace is co-owned by multiple individuals or teams, it can make management of the content complicated. Try to avoid multi-team ownership scenarios by separating out workspaces. That way, responsibilities are clear and role assignments are straightforward to set up.
There are two variations to the four workspace roles (described previously).
Important
Per-item permissions can also be thought of as an override of the standard workspace roles. For more information about per-item permissions, see the Report consumer security planning article.
Checklist - When planning for workspace roles, key decisions and actions include:
Content creators who are workspace administrators or members can create and publish a Power BI app.
A workspace administrator can also specify a setting in the workspace which allows workspace contributors to update the app. It's a variation to workspace role security because it grants contributors one other permission they wouldn't normally have. This setting is set on a per-workspace basis.
Tip
For more information about delivering content to read-only consumers, see the Report consumer security planning article. This article includes information about app permissions for app consumers, including audiences for the app.
Checklist - When planning for app creator permissions, key decisions and actions include:
When a data creator starts a new project, permissions required to access external data sources are one of their first security-related considerations. They might also need guidance on other data source related matters, including privacy levels, native database queries, and custom connectors.
When a data creator creates a semantic model, dataflow, or datamart, they must authenticate with data sources to retrieve data. Usually, authentication involves user credentials (account and password), which could be for a service account.
Sometimes it's useful to create specific service accounts for accessing data sources. Check with your IT department for guidance on how service accounts should be used in your organization. When they're permitted, the use of service accounts can:
Tip
If you choose to use service accounts, we recommend that you tightly control who has access to the credentials. Rotate passwords on a regular basis (such as every three months) or when someone that has access leaves the organization.
When accessing data sources, apply the principle of least privilege to ensure that users (or service accounts) have permission to read only the data they need. They should never have permission to perform data modifications. Database administrators who create these service accounts should inquire about expected queries and workloads and take steps to ensure adequate optimizations (like indexes) and resources are in place.
Tip
If it's difficult to provide direct data source access to self-service data creators, consider using an indirect approach. You can create dataflows in the Power BI service and allow self-service data creators to source data from them. This approach has the added benefits of reducing the query load on the data source and delivering a consistent snapshot of data. For more information, see the self-service data preparation and advanced data preparation usage scenarios.
The credentials (account and password) can be applied in one of two ways.
Tip
When you've already entered credentials for a semantic model data source, the Power BI service will automatically bind those credentials to other semantic model data sources when there's an exact match of connection string and database name. Both the Power BI service and Power BI Desktop make it look like you're entering credentials for each data source. However, it can apply the same credentials to matching data sources that have the same owner. In that respect, semantic model credentials are scoped to the owner.
Credentials are encrypted and stored separately from the data model in both Power BI Desktop and the Power BI service. This data separation has the following security advantages.
Some data sources support single-sign on (SSO), which can be set when entering credentials in the Power BI service (for semantic model or gateway data sources). When you enable SSO, Power BI sends the authenticated user's credentials to the data source. This option enables Power BI to honor the security settings that are set up in the data source, such as row-level security. SSO is especially useful when tables in the data model use DirectQuery storage mode.
Data privacy levels specify isolation levels that define the degree that one data source is isolated from other data sources. When appropriately set, they ensure that Power Query only transmits compatible data between sources. When Power Query can transmit data between data sources, it can result in more efficient queries that reduce the volume of data that's sent to Power BI. When it can't transmit data between data sources, it can result in slower performance.
There are three privacy levels.
When combining queries from different data sources, it's important that you set the correct privacy levels. When privacy levels are set correctly, there's the potential for data from one data source to be transmitted to another data source to efficiently query data.
Consider a scenario where a semantic model creator has two data sources: an Excel workbook and a table in an Azure SQL Database. They want to filter the data in the Azure SQL Database table by using a value sourced from the Excel workbook. The most efficient way for Power Query to generate a SQL statement for the Azure SQL Database is to apply a WHERE
clause to perform the necessary filtering. However, that SQL Statement will contain a WHERE
clause predicate with a value sourced from the Excel workbook. If the Excel workbook contains sensitive data, it could represent a security breach because the database administrator could view the SQL statement by using a tracing tool. While less efficient, the alternative is for the Power Query mashup engine to download the entire result set of the database table and perform the filtering itself in the Power BI service. This approach will be less efficient and slow, but secure.
Privacy levels can be set for each data source:
Important
The privacy levels that you set in Power BI Desktop aren't transferred to the Power BI service.
There's a Power BI Desktop security option that allows ignoring privacy levels to improve performance. You might use this option to improve query performance while developing a data model when there's no risk of breaching data security (because you're working with development or test data that isn't sensitive). However, this setting isn't honored by the Power BI service.
For more information, see Power BI Desktop privacy levels.
To create efficient Power Query queries, you can use a native query to access data. A native query is a statement written in a language supported by the data source. Native queries are only supported by specific data sources, which are typically relational databases like Azure SQL Database.
Native queries can pose a security risk because they could run a malicious SQL statement. A malicious statement could perform data modifications or delete database records (when the user has the required permissions in the data source). For this reason, by default, native queries require user approval to run in Power BI Desktop.
There's a Power BI Desktop security option that allows you to disable the requirement for pre-approval. We recommend that you leave the default setting that requires user approval, especially when you anticipate that the Power BI Desktop file could be refreshed by other users.
Developers can use the Power Query SDK to create custom connectors. Custom connectors allow access to proprietary data sources or implement specific authentication with custom data extensions. Some custom connectors are certified and distributed by Microsoft as certified connectors. Certified connectors have been audited and reviewed to ensure that they meet certain specified code requirements that Microsoft has tested and approved.
There's a Power BI Desktop data extension security option that restricts the use of non-certified connectors. By default, an error is raised when an attempt is made to load a non-certified connector. By setting this option to allow non-certified connectors, custom connectors will load without validation or warning.
We recommend that you keep your data extension security level at the higher level, which prevents loading of non-certified code. However, there might be cases where you want to load specific connectors, perhaps connectors that you've developed, or connectors provided to you by a trusted consultant or vendor outside the Microsoft certification path.
Note
Developers of in-house-developed connectors can take steps to sign a connector with a certificate, allowing you to use the connector without the need to change your security settings. For more information, see Trusted third-party connectors.
Checklist - When planning data source permissions, key decisions and actions include:
You can assign permission to edit a semantic model to a user or group in different ways.
In the following screenshot, notice the permissions assigned to the Call Center Data semantic model. One user has Read permission, which was granted by using per-item direct access permissions. The remaining users and groups have permissions because they're assigned to workspace roles.
Tip
Using per-item permissions (links or direct access) works best when the intention is for a user or group to view or edit one specific item in the workspace. It's best suited when the user isn't permitted to access all items in the workspace. In most cases, we recommend that you design your workspaces so that security is simpler to manage with workspace roles. Avoid setting per-item permissions whenever possible.
You can assign the following semantic model permissions.
A workspace administrator or member can edit the permissions for a semantic model.
The semantic model Read permission is primarily targeted at consumers. This permission is required for users to be able to view data that's displayed in reports. Be aware that reports based on the semantic model must also have Read permission; otherwise, the report will fail to load. For more information about setting report Read permissions, see the Report consumer security planning article.
In addition to semantic model Read permission, content creators also need the semantic model Build permission. Specifically, the Build permission allows report creators to:
You can grant Build permission to a user or group, directly or indirectly, in different ways.
Setting Build permission directly for a semantic model is appropriate when you want to manage security on a granular, per-item basis. Setting Build permission indirectly is appropriate when the users who will view or use the content through one of the indirect methods will also create new content.
Tip
Frequently, the users who view a report or a Power BI app are different from the users who create new content by using the underlying semantic model(s). Most consumers are viewers only, so they don't need to create new content. We recommend that you educate your content creators to grant the least number of permissions that are required.
Usually, setting permissions for who can edit and manage semantic models will be done by assigning users to either the Admin, Member, or Contributor workspace role. However, it's also possible to set Write permission for a specific semantic model.
We recommend that you use workspace roles whenever possible because it's the simplest way to manage and audit permissions. Use the semantic model Write permissions on a per-item basis when you've chosen to create fewer workspaces, and a workspace contains semantic models for different subject areas that require different permissions management.
Tip
For guidance on how to organize workspaces, see the workspace planning articles.
The semantic model Reshare permission allows a user with existing permission to share the semantic model with other users. You can grant this permission when content in the semantic model can be freely shared, based on user discretion.
In many cases, we recommend limiting the use of the Reshare permission to ensure that semantic model permissions are carefully controlled. Get approval from the semantic model owner(s) before granting the Reshare permission.
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.
A semantic model creator can enforce data security in two ways.
The implementation of RLS and OLS are targeted at report consumers. For more information, see Report consumer security planning article. It describes how and when RLS and OLS are enforced for consumers who have view-only permission to the semantic model.
For RLS and OLS targeted at other report creators, see data security in the Report creator permissions section later in this article.
Power BI semantic models can connect to other semantic models in a process known as chaining, which are connections to upstream semantic models. For more information, see Use composite models in Power BI Desktop.
The Allow DirectQuery connections to Power BI semantic models tenant setting allows Power BI administrators to set up which groups of content creators can create chained semantic models. If you don't want to restrict semantic model creators from chaining semantic models, you can leave this setting enabled for the entire organization and rely on workspace access and semantic model permissions. In some cases, you might consider restricting this capability to approved content creators.
Note
As a semantic model creator, you can restrict chaining to your semantic model. It's done by enabling the Discourage DirectQuery connection to this semantic model option in Power BI Desktop. For more information, see Manage DirectQuery connections to a published semantic model.
In some situations, you might want to execute a DAX query by using the Power BI REST API. For example, you might want to perform data quality validations. For more information, see Datasets - Execute Queries.
The Dataset Execute Queries REST API tenant setting allows Power BI administrators to set which groups of users can send DAX queries by using the Power BI REST API. In most cases, you can leave this setting enabled for the entire organization and rely on workspace access and semantic model permissions. In some cases, you might consider restricting this capability to approved content creators.
Checklist - When planning for semantic model creator permissions, key decisions and actions include:
Report creators need workspace access to create reports in the Power BI service or publish them from Power BI Desktop. They must be either an administrator, member, or contributor in the target workspace.
Whenever possible, report creators should use an existing shared semantic model (via a live connection or DirectQuery). That way, the report creation process is decoupled from the semantic model creation process. This type of separation provides many benefits for security and team development scenarios.
A report creator needs to be a workspace administrator, member, or contributor.
Unlike semantic models, there isn't a Write permission for reports. To support report creators, workspace roles must be used. For this reason, optimal workspace design is important to balance content organization and security needs.
Tip
For permissions to support report consumers (including the Read and Reshare per-item permissions), see the Report consumer security planning article.
Report creators must have Read and Build permissions on the semantic models that their reports will use, which includes chained semantic models. That permission can be granted explicitly on the individual semantic models, or it can be granted implicitly for workspace semantic models when the report creator is a workspace administrator, member, or contributor.
The Use semantic models across workspaces tenant setting allows Power BI administrators to set up which groups of users can create reports that use semantic models located in other workspaces. This setting is targeted at semantic model and report creators. Usually, we recommend that you leave this setting enabled for the entire organization and relying on workspace access settings and semantic model permissions. That way, you can encourage the use of existing semantic models. In some cases, you might consider restricting this capability only to approved content creators.
There's also the Allow live connections tenant setting, which allows Power BI administrators to set up which groups of users can create live connections to semantic models in Power BI Desktop or Excel. It's targeted specifically at report creators, and it also requires that they're granted Read and Build permission on the semantic model that the report will use. We recommend that you leave this setting enabled for the entire organization and rely on workspace access and semantic model permissions. That way, you can encourage the use of existing semantic models. In some cases, you might consider restricting this capability only to approved content creators.
RLS and OLS (described previously in this article) are targeted at report consumers. However, sometimes it also needs to be enforced for report creators. Creating separate workspaces is justified when RLS needs to be enforced for report creators and also report consumers.
Consider the following scenario.
For more information about RLS and OLS, see the Report consumer security planning article. It describes how and when RLS and OLS are enforced for consumers who have view-only permission to the semantic model.
When a report creator connects to a shared semantic model for their report, they usually connect to a shared semantic model that's been published in their own Power BI tenant. When permission has been granted, it's also possible to connect to a shared semantic model in another tenant. The other tenant could be a partner, customer, or vendor.
This functionality is known as in-place semantic model sharing (also known as cross-tenant semantic model sharing). The reports created by the report creator (or new composite models created by a semantic model creator) are stored and secured in your Power BI tenant by using your normal process. The original shared semantic model remains in its original Power BI tenant, and all permissions are managed there.
For more information, see the Tenant-level security planning article. It includes information about the tenant settings and semantic model settings that make external sharing work.
In Power BI Desktop, semantic model creators can set a model table to become a featured table. When the semantic model is published to the Power BI service, report creators can use the Data Types Gallery in Excel to find the featured table, allowing them to add featured table data to augment their Excel worksheets.
The Allow connections to featured tables tenant setting allows Fabric administrators to set up which groups of users can access featured tables. It's targeted at Excel users who want to access Power BI featured tables in Excel organization data types. We recommend that you leave this setting enabled for the entire organization and rely on workspace access and semantic model permissions. That way, you can encourage the use of featured tables.
In addition to core visuals, Power BI report creators can use custom visuals. In Power BI Desktop, custom visuals can be download from Microsoft AppSource. They can also be developed in-house by using the Power BI SDK, and installed by opening the visual file (.pbviz).
Some visuals available for download from AppSource are certified visuals. Certified visuals meet certain specified code requirements that the Power BI team has tested and approved. The tests check that visuals don't access external services or resources.
The Allow visuals created by the Power BI SDK tenant setting allows Power BI administrators to control which groups of users can use custom visuals.
There's also the Add and use certified visuals only tenant setting, which allows Power BI administrators to block the use of non-certified visuals in the Power BI service. This setting can be enabled or disabled for the entire organization.
Note
If you block the use of non-certified visuals, it only applies to the Power BI service. If you want to restrict their use in Power BI Desktop, ask your Fabric administrator to use a group policy setting to block their use in Power BI Desktop. Taking this step will ensure that report creators don't waste time and effort creating a report that won't work when published to the Power BI service. We highly recommend that you set up your users to have consistent experiences in the Power BI service (with the tenant setting) and Power BI Desktop (with group policy).
Power BI Desktop has an option to show a security warning when a report creator adds a custom visual to the report. Report creators can disable this option. This option doesn't test whether the visual is certified.
Power BI administrators can approve and deploy custom visuals for their organization. Report creators can then easily discover, update, and use these visuals. Administrators can then manage these visuals by updating versions or disabling and enabling specific custom visuals. This approach is useful when you want to make an in-house-developed visual available to your report creators, or when you acquire a custom visual from a vendor that isn't in AppSource. For more information, see Power BI organizational visuals.
Consider a balanced strategy of enabling only certified custom visuals in your organization (with the tenant setting and group policy previously described), while deploying organizational visuals to handle any exceptions.
Checklist - When planning for report creator permissions, key decisions and actions include:
Dataflows are helpful for centralizing data preparation so that the work done in Power Query isn't repeated across many semantic models. They're a building block for achieving a single source of truth, preventing analysts from requiring direct access to sources, and for helping to perform extract, transform, and load (ETL) operations at scale.
A dataflow creator needs to be a workspace administrator, member, or contributor.
To consume a dataflow (for instance, from a new data model created in Power BI Desktop or in another workspace), a semantic model creator can belong to any workspace role, including the Viewer role. There's no concept of RLS for dataflows.
In addition to workspace roles, the Create and use dataflows tenant setting must be enabled. This tenant setting applies to the entire organization.
Consider the following scenario.
For more information about using dataflows, see the self-service data preparation and advanced data preparation usage scenarios.
Checklist - When planning for dataflow creator permissions, key decisions and actions include:
A datamart is a self-service analytics solution that enables users to store and explore data that's loaded in a fully managed relational database. It also comprises an auto-generated semantic model.
Datamarts provide a simple low-code experience to ingest data from different data sources, and to extract, transform, and load (ETL) the data by using Power Query Online. The data is loaded into an Azure SQL Database that's fully managed and requires no tuning or optimization. The auto-generated semantic model is always synchronized with the managed database because it's in DirectQuery mode.
You can create a datamart when you're either a workspace administrator, member, or contributor. Workspace roles also get mapped to database-level roles in the Azure SQL Database (however, because the database is fully managed, user permissions can't be edited or managed in the relational database).
The Create datamarts tenant setting allows Power BI administrators to set up which groups of users can create datamarts.
For datamarts, the term sharing takes on a meaning that's different to other Power BI content types. Usually, a sharing operation is targeted at a consumer because it provides read-only permission to one item, like a report.
Sharing a datamart is targeted at content creators (rather than consumers). It grants the Read and Build permissions, which allows users to query either the semantic model or the relational database, whichever they prefer.
Sharing a datamart allows content creators to:
You can define RLS for datamarts to restrict data access for specified users. RLS is set up in the datamart editor in the Power BI service, and it's automatically applied to the auto-generated semantic model and the Azure SQL Database (as security rules).
Regardless of how a user chooses to connect to the datamart (to the semantic model or the database), identical RLS permissions are enforced.
Checklist - When planning for datamart creator permissions, key decisions and actions include:
Metrics in Power BI let you curate specific metrics and track them against key business objectives. Metrics are added to scorecards, which can be shared with other users and viewed in a single pane.
Scorecards can be secured with three levels of permissions:
A user who creates, or fully manages, a scorecard needs to be a workspace administrator, member, or contributor.
Because metrics often span multiple subject areas, we recommend that you create a separate workspace so that you can independently manage permissions for creators and consumers.
The Create and use metrics tenant setting allows Power BI administrators to set up which groups of users can create scorecard metrics.
You can assign the following scorecard permissions.
Consistent with other content types in the Power BI service, the per-item permissions are useful when the intention is to share one item with another user. We recommend using workspace roles and app permissions whenever possible.
Each scorecard has a set of metric-level permissions that you can set up in the scorecard settings. The metric-level permissions (within a scorecard) can be granted differently from the workspace or the scorecard (per-item) permissions.
The metric-level roles allow you to set:
To reduce the level of future maintenance, it's possible to set default permissions that will be inherited by submetrics you create in the future.
Checklist - When planning for metric creator permissions, key decisions and actions include:
This section includes topics related to publishing content that are relevant to content creators.
Content creators will need administrator, member, or contributor role access to publish content to a workspace. For more information, see the workspace roles described earlier in this article.
Except for personal BI, content creators should be encouraged to publish content to standard workspaces, instead of their personal workspace.
The Block republish and disable package refresh tenant setting changes the behavior for publishing semantic models. When enabled, workspace administrators, members, or contributors can't publish changes to a semantic model. Only the semantic model owner is permitted to publish an update (forcing the takeover of a semantic model before publishing an updated semantic model). Because this tenant setting applies to the entire organization, enable it with a measure of caution because it affects all semantic models for the entire tenant. Be sure to communicate to your semantic model creators what to expect because it changes the normal behavior of workspace roles.
It's possible to create a Power Apps solution that includes embedded Power BI reports. The Power Apps process will automatically create a dedicated Power BI workspace for storing and securing the Power BI reports and semantic models. To manage items that exist in both Power Apps and Power BI, there's a synchronization process.
The process synchronizes security roles to ensure that Power BI inherits the same roles that were initially set up in Power Apps. It also allows the content creator to manage permissions for who can view the Power BI reports (and related semantic models) that are embedded in a Power App.
For more information about synchronizing Power Apps roles with Power BI workspace roles, see Permission sync between Power Apps environment and Power BI workspace.
Content creators and owners can use Power BI deployment pipelines for self-service content publishing. Deployment pipelines simplify the publication process and improve the level of control when releasing new content.
You manage pipeline permissions (for users who can deploy content with a deployment pipeline) separately from the workspace roles. Access to both the workspace and the deployment pipeline are required for the users conducting a deployment.
Content creators might also need:
Important
At times this article refers to Power BI Premium or its capacity subscriptions (P SKUs). Be aware that Microsoft is currently consolidating purchase options and retiring the Power BI Premium per capacity SKUs. New and existing customers should consider purchasing Fabric capacity subscriptions (F SKUs) instead.
For more information, see Important update coming to Power BI Premium licensing and Power BI Premium FAQ.
For more information, see Deployment pipeline access.
The XMLA endpoint uses the XMLA protocol to expose all features of a tabular data model, including some data modeling operations that aren't supported by Power BI Desktop. You can use the Tabular Object Model (TOM) API to make programmatic changes to a data model.
The XMLA endpoint also provides connectivity. You can only connect to a semantic model when the workspace has its license mode set to Premium per user, Premium per capacity, or Embedded. Once a connection is made, an XMLA-compliant tool can operate on the data model to read or write data. For more information about how you can use the XMLA endpoint for managing a semantic model, see the advanced data model management usage scenario.
Access through the XMLA endpoint will honor existing permissions. Workspace administrators, members, and contributors implicitly have semantic model Write permission, which means they can deploy new semantic models from Visual Studio and execute Tabular Modeling Scripting Language (TMSL) scripts in SQL Server Management Studio (SSMS).
Users with the semantic model Build permission can use the XMLA endpoint to connect to and browse semantic models for data consumption and visualization. RLS rules are honored, and users can't see internal semantic model metadata.
The Allow XMLA endpoints and Analyze in Excel with on-premises semantic models tenant setting refers to two capabilities: It controls which groups of users can use the XMLA endpoint to query and/or maintain semantic models in the Power BI service. It also determines whether Analyze in Excel can be used with on-premises SQL Server Analysis Services (SSAS) models.
Note
The Analyze in Excel aspect of that tenant setting only applies to on-premises SQL Server Analysis Services (SSAS) models. The standard Analyze in Excel functionality, which connects to a Power BI semantic model in the Power BI service, is controlled by the Allow Live Connections tenant setting.
Publish to web is a feature that provides access to Power BI reports to anyone on the internet. It doesn't require authentication and access isn't logged for auditing purposes. Because report consumers don't need to belong to the organization or have a Power BI license, this technique is well suited to data journalism, a process where reports are embedded in blog posts, websites, emails, or social media.
Caution
Publish to web has the potential to expose sensitive or confidential data, whether accidentally or intentionally. For this reason, this feature is disabled by default. Publish to web should only be used for reports that contain data that can be viewed by the public.
The Publish to web tenant setting allows Power BI administrators to control which groups of users can publish reports to the web. To maintain a higher level of control, we recommend that you don't include other groups in this tenant setting (like Power BI administrators or other types of content creators). Instead, enforce specific user access by using a security group such as Power BI public publishing. Ensure that the security group is well managed.
The Embed content in apps tenant setting allows Power BI administrators to control which users can embed Power BI content outside of the Power BI service. When you plan to embed Power BI content in custom applications, enable this setting for specific groups, such as app developers.
The Enable Power BI add-in for PowerPoint tenant setting allows Power BI administrators to control which users can embed Power BI report pages in PowerPoint presentations. When appropriate, enable this setting for specific groups, such as report creators.
Note
For this capability to work, users must install the Power BI add-in for PowerPoint. To use the add-in, users must either have access to the Office add-in store, or the add-in must be made available to them as an admin managed add-in. For more information, see Power BI add-in for PowerPoint.
Educate report creators to be cautious about where they save their PowerPoint presentations and who they share them with. That's because an image of the Power BI report visuals is shown to users when they open the presentation. That image is captured from the last time the PowerPoint file was connected. However, the image could inadvertently reveal data that the receiving user doesn't have permission to see.
Note
The image can be useful when the receiving user doesn't yet have the add-in, or until the add-in connects to the Power BI service to retrieve data. Once the user connects, only data the user can see (enforcing any RLS) is retrieved from Power BI.
Template apps enable Power BI partners and software vendors to build Power BI apps with little or no coding, and deploy them to any Power BI customer.
The Publish template apps tenant setting allows Power BI administrators to control which users can publish template apps outside of the organization, such as through Microsoft AppSource. For most organizations, this tenant setting should be disabled or tightly controlled. Consider using a security group such as Power BI external template app creators.
You can subscribe yourself and others to Power BI reports, dashboards, and paginated reports. Power BI will then send an email on a schedule you set. The email will contain a snapshot and link to the report or dashboard.
You can create a subscription that includes other users when you're a workspace administrator, member, or contributor. If the report is in a Premium workspace, you can subscribe groups (whether they're in your domain or not) and external users. When setting up the subscription, there's also the option to grant permissions to the item. Per-item direct access permissions are used for this purpose, which are described in the Report consumer security planning article.
Caution
The email subscription feature has the potential to share content to internal and external audiences. Also, when RLS is enforced on the underlying semantic model, attachments and images are generated by using the security context of the subscribing user.
The Email subscriptions tenant setting allows Power BI administrators to control whether this feature is enabled or disabled for the entire organization.
There are some limitations concerning attachments related to licensing and tenant setting restrictions. For more information, see Email subscriptions for reports and dashboards in the Power BI service.
Checklist - When planning for publishing content, key decisions and actions include:
Once published, data creators should ensure that their semantic models and dataflows (that contain imported data) are periodically refreshed. You should also decide on appropriate strategies for the semantic model and dataflow owners.
Each semantic model has an owner, which is a single user account. The semantic model owner is required to set up semantic model refresh and set semantic model parameters.
By default, the semantic model owner also receives access requests from report creators who want Build permissions (unless the Request access settings for the semantic model are set to provide custom instructions). For more information, see the Request access workflow for creators section in this article.
There are two ways that Power BI can obtain credentials to refresh a semantic model.
If a different user needs to set up refresh or set semantic model parameters, they must take ownership of the semantic model. semantic model ownership can be taken over by a workspace administrator, member, or contributor.
Caution
Taking semantic model ownership permanently removes any stored credentials for the semantic model. Credentials must be re-entered to allow data refresh operations to resume.
Ideally, the semantic model owner is the user who's responsible for the semantic model. You should update the semantic model owner when they leave the organization or change roles. Also, be aware that when the semantic model owner's user account is disabled in Microsoft Entra ID, data refresh is automatically disabled. In this case, another user must take ownership of the semantic model to allow data refresh operations to resume.
Like semantic models, dataflows also have an owner, which is a single user account. The information and guidance provided in the previous topic about semantic model owners also applies to dataflow owners.
Checklist - When planning for security related to data refresh processes, key decisions and actions include:
For other considerations, actions, decision-making criteria, and recommendations to help you with Power BI implementation decisions, see the subject areas to consider.
Events
Power BI DataViz World Championships
Feb 14, 4 PM - Mar 31, 4 PM
With 4 chances to enter, you could win a conference package and make it to the LIVE Grand Finale in Las Vegas
Learn moreTraining
Module
Secure, publish, and share data in Power BI - Training
Learn how to secure, share, and publish Microsoft Power BI reports as part of the Power BI service. Understand workspaces and certification.
Certification
Microsoft Certified: Power BI Data Analyst Associate - Certifications
Demonstrate methods and best practices that align with business and technical requirements for modeling, visualizing, and analyzing data with Microsoft Power BI.
Documentation
Power BI implementation planning: Tenant-level security planning - Power BI
Learn about tenant-level security planning for Power BI.
Power BI implementation planning: Report consumer security planning - Power BI
Learn about report consumer security planning for Power BI.
Power BI implementation planning: Content distribution and sharing - Power BI
This article helps you to plan the distribution and sharing of content in Power BI and Microsoft Fabric.