Power BI usage scenarios: Self-service content publishing
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.
When analytical solutions are critical to the organization, it's important to ensure content in the Power BI service is stable and reliable for consumers. IT teams often solve this problem by working in multiple environments:
- In the development environment, content creators and owners make changes and improvements to the solution. When these changes are ready for broader review, the solution is deployed (sometimes known as promoted) to the test environment.
- In the test environment, reviewers validate the changes made to the solution. This review can involve validating the solution functionality and data. When the review is complete, the solution is deployed to the production environment.
- The production environment is where consumers view and interact with the released solution.
This structured approach ensures that content creators, owners, and reviewers can make and validate changes without negatively affecting consumers.
Using methodical and disciplined lifecycle management processes reduces errors, minimizes inconsistencies, and improves the user experience for consumers. Content creators and owners can use Power BI deployment pipelines for self-service content publishing. Deployment pipelines simplify the process and improve the level of control when releasing new content.
Note
This self-service content publishing scenario is one of the content management and deployment scenarios. For a complete list of the self-service scenarios, see the Power BI usage scenarios article.
For brevity, some aspects described in the content collaboration and delivery scenarios topic aren't covered in this article. For complete coverage, read those articles first.
Scenario diagram
The following diagram depicts a high-level overview of the most common user actions and Power BI components to support self-service content publishing. The focus is on use of a Power BI deployment pipeline for promoting content through development, test, and production workspaces.
Tip
We encourage you to download the scenario diagram if you'd like to embed it in your presentation, documentation, or blog post—or print it out as a wall poster. Because it's a Scalable Vector Graphics (SVG) image, you can scale it up or down without any loss of quality.
The scenario diagram depicts the following user actions, tools, and features:
| Item | Description |
|---|---|
 |
The Power BI content creator develops a BI solution using Power BI Desktop. |
 |
The Power BI Desktop file (.pbix) of Power BI project file (.pbip) is saved to a shared library in OneDrive. The content creator retains versions of these files in OneDrive. |
 |
When ready, the content creator publishes the Power BI Desktop file to the Power BI service. |
 |
Content is published to a workspace that's dedicated to development. |
 |
A deployment pipeline administrator sets up the Power BI deployment pipeline with three stages: development, test, and production. Each stage aligns to a separate workspace in the Power BI service. Deployment settings and access are set up for the deployment pipeline. |
 |
The development (or test) workspace is set to Fabric capacity, Premium capacity, Premium Per User, or Embedded license mode. Power BI deployment pipelines are a feature available only in workspaces with these license modes. |
 |
Content creators and owners collaborate in the development workspace to ensure all requirements are met. |
 |
When the development content is ready, the deployment pipeline compares the content between the development and test stages. |
 |
Some, or all, Power BI items are deployed to a workspace that's dedicated to testing. |
 |
Once the deployment pipeline has completed its deployment, the content creator manually performs post-deployment activities for the test workspace. Activities can include configuring scheduled data refresh or publishing a Power BI app for the test workspace. |
 |
Quality assurance, data validations, and user acceptance testing occur by reviewers of the test workspace. |
 |
When the test content is fully validated, the deployment pipeline compares the content between the test and production stages. |
 |
Some, or all, Power BI items are deployed to a workspace that's dedicated to production. For a production workspace, Fabric capacity or Premium capacity license mode is often more appropriate when there's a large number of read-only consumers. |
 |
After the deployment pipeline completes deployment, content creators can manually perform post-deployment activities. Activities can include configuring scheduled data refresh or publishing a Power BI app for the production workspace. |
 |
Content viewers access the content using the production workspace or a Power BI app. |
 |
Some data sources may require an On-premises data gateway or VNet gateway for data refresh, like those that reside within a private organizational network. |
 |
Fabric administrators oversee and monitor activity in the Fabric portal. Content that's deemed critical enough to have separate development, test, and production workspaces could be subject to stricter governance requirements than less critical content. |
Tip
We recommend that you reviewing the advanced data model management usage scenario as too. It builds upon concepts introduced in this scenario.
Key points
The following are some key points to emphasize about the self-service content publishing scenario.
Deployment pipeline
A deployment pipeline consists of three stages: development, test, and production. A single workspace is assigned to each stage in the deployment pipeline. Power BI items that are supported by deployment pipelines are published (or cloned) from one workspace to another when a deployment occurs. Once testing and validations are complete, the deployment pipeline can be reused many times to promote content quickly. The deployment pipeline interface is easy to implement for content creators who don't have the skills or desire to use code-based deployments (use of the Power BI REST APIs are described in the enterprise content publishing scenario).
Note
Publishing content using a deployment pipeline is known as a metadata-only deployment. In this case, data isn't overwritten or copied to the target workspace. A data refresh is usually required once the deployment completes—see the post-deployment activities topic below.
Deployment process
It's a best practice to consider the entire workspace content as an analytical package that can be deployed together as a unit. Therefore, it's important to have clarity on the purpose and expectations of each workspace. Although a selective deployment of specific Power BI items is possible, it's more efficient and less risky when a deployment represents a logical unit of content.
Tip
Plan for how urgent issues will be handled, in addition to planned deployments. If an immediate fix is required, still follow the standard practice of propagating all changes from development through to test and production using the deployment pipeline.
Permissions model
Spend time planning the permissions model. Full flexibility for applying different workspace roles (between development, test, and production) is supported. As depicted in the scenario diagram, it's common to assign the following workspace permissions:
- Development workspace: Limit access to a team of content creators and owners who collaborate together.
- Test workspace: Limit access to reviewers involved with quality assurance, data validations, and user acceptance testing activities.
- Production workspace: Grant viewer access to content consumers of the Power BI app (and the workspace, when appropriate). Limit access to those who need to manage and publish production content, involving the fewest number of users possible.
Note
Most content consumers are unaware of the development and test workspaces.
Access for deployment pipeline
Pipeline user permissions (for who can deploy content with a deployment pipeline) are managed separately from the workspace roles. Access to both the workspace and the deployment pipeline are required for the users conducting a deployment. Relevant Premium permissions are also required.
When possible, it's recommended that the existing content creator or owner conduct the deployments. In some situations, permissions are more restricted for the production workspace. In that case, it might be appropriate to coordinate the production deployment with someone else who has permission to deploy to production.
Pipeline users who are assigned to the workspace member (or admin) role are allowed to compare stages and deploy content. Assigning pipeline users to this role minimizes permissions issues and allows for a smoother deployment process.
Tip
Keep in mind that workspace roles are set separately for development, test, and production. However, pipeline access is set once for the entire pipeline.
Power BI Premium licensing
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.
Power BI deployment pipelines are a Premium feature. There are various ways to obtain licensing, depending on whether the content is used for development, test, or production purposes. The scenario diagram depicts use of a Premium P SKUs such as P1, P2, P3, P4, or P5 for the production workspace, and a Power BI Premium Per User (PPU) user-based Premium license for the development and test workspaces. Using PPU licensing for workspaces with very few users (as depicted in the scenario diagram) is a cost-effective way to use Premium features, while keeping them separate from the Premium capacity that's assigned for production workloads.
Deployment settings
Data source rules and parameter rules are available for dynamically managing values that differ between development, test, and production. Use of deployment settings are an effective way to reduce effort and the risk of errors.
Post-deployment activities
Purposefully, certain properties aren't copied to the target workspace during a deployment. Several key post-deployment activities include:
- Data refresh: Data isn't copied from the source workspace to the target workspace. Publishing from a deployment pipeline is always a metadata-only deployment. Therefore, a data refresh is usually required after deploying to a target workspace. For first-time deployments, the data source credentials or gateway connectivity (as appropriate) must be configured as well.
- Apps: Power BI apps aren't published automatically by deployment pipelines.
- Access roles, sharing permissions, and app permissions: Permissions aren't overwritten during a deployment.
- Workspace properties: Properties, such as contacts and the workspace description, aren't overwritten during a deployment.
- Power BI item properties: Certain Power BI item properties, such as sensitivity labels, might be overwritten during a deployment in certain circumstances.
- Unsupported Power BI items: Additional manual steps might need to be taken for Power BI items that aren't supported by the deployment pipeline.
Caution
There isn't a rollback process once a deployment has occurred with a deployment pipeline. Consider carefully what change management processes and approvals are required in order to deploy to the production workspace.
OneDrive storage
The scenario diagram depicts using OneDrive for storing the source Power BI Desktop files. The goal is to store the source files in a location that is:
- Appropriately secured to ensure only publishers can access the source files. A shared library (rather than a personal library) is a good choice.
- Backed up frequently so the files are safe from loss.
- Versioned when changes occur, to allow for a rollback to an earlier version.
Tip
If a OneDrive location is synchronized to a workspace, configure it only for the development workspace.
Gateway setup
Typically, a data gateway is required when accessing data sources that reside within the private organizational network or a virtual network. The On-premises data gateway becomes relevant once a Power BI Desktop file is published to the Power BI service. The two purposes of a gateway are to refresh imported data, or view a report that queries a live connection or DirectQuery semantic model (not depicted in the scenario diagram).
When working with multiple environments, it's common to configure development, test, and production connections to use different source systems. In this case, use data source rules and parameter rules to manage values that differ between environments.
Note
A centralized data gateway in standard mode is strongly recommended over gateways in personal mode. In standard mode, the data gateway supports live connection and DirectQuery operations (in addition to scheduled data refresh operations).
System oversight
The activity log records user activities that occur in the Power BI service. Power BI administrators can use the activity log data that's collected to perform auditing to help them understand deployment activities that occur.
Related content
In the next article in the series, learn about the advanced data modeling usage scenario.