Problem
Deployment Pipelines are not a new feature in Power BI. Many articles, blogs, and tips have been written about it over the years. However, most people still do not fully understand certain facts and features related to Deployment Pipelines, resulting in lost time while answering the numerous questions from business stakeholders on these facts. It is understandable why stakeholders/analysts are unsure of all the features: the large amounts of Microsoft documentation and articles to review and comprehend can be overwhelming, especially if you do not work with Power BI daily. This tip provides insights into some common questions I have been asked relating to Power BI Deployment Pipeline features.
Solution
For this tip, I assume you are either new to Deployment Pipelines or you need some technical information to guide your use of the feature. You can read more about how to get started with deployment pipelines in this Microsoft documentation.
Permission / Access
The first thing we will look at is permissions and providing the necessary access.
Access Permissions in Deployment Pipelines are Separate from Workspace Access Permissions
Managing the Deployment Pipeline access can be done within the deployment pipeline, as seen in the image below. You cannot leverage the permissions you have in your Workspace for a Deployment Pipeline. You need to navigate to your deployment pipeline to manage access.
Only Admin Access Permission is Permitted to a Deployment Pipeline
Currently, you can only assign a user Admin access permission to a deployment pipeline. Thus, a user who has access to your deployment pipeline will have Admin access permission. See the image below.
Requirements to Participate in the Deployment Process
To partake in the deployment process, you will need:
- Admin, Member, or Contributor access to a workspace
- The deployment pipeline shared with you (resulting in Admin access permission to the deployment pipeline).
Ability to View a Deployment Pipeline on the Workspace
By default, end users with Workspace access will be able to see a deployment pipeline on the Workspace, but only on the Production stage. Depending on how many environments/stages you have created, by default, end users without access to the deployment pipelines will not know or see that there is a deployment pipeline associated with a workspace, unless the workspace is the production stage workspace.
However, you can manually change this per workspace by switching on the “Set as public” button on the stage settings, as seen in the image below.
Licensing / Capacity Limitations
Only Premium Capacity Workspace (Contents) can be Assigned in a Deployment Pipelines Stage.
Currently, if you use a Pro license in Power BI, you cannot leverage Deployment Pipelines since it’s a Premium feature. You need a Premium Per User, a Premium Capacity, or a Fabric Capacity to use the Deployment Pipelines feature.
Deployments – What is Not Copied, Inherited, or Carried Over to the Next Stage
In this section, we cover what is not copied from one stage to another stage.
No Data, Only Metadata
When deploying from one stage to another, your data is not deployed (copied); it remains securely in its current location. What is copied is the metadata, which includes information about the structure, properties, and relationships of the data. This is done to enhance security and reduce data exposure.
Personal Bookmarks
To ensure a consistent user experience for every user in each stage of the deployment, personalized views or filters, saved as personal bookmarks, are not migrated between stages.
Workspace Settings
In a deployment pipeline, every stage individually maintains and owns workspace settings. Workspace-specific properties like appearance settings, custom configurations, or other workspace settings are not migrated to the next stage. This helps to ensure that each environment is managed separately.
App Contents of Apps
With deployment pipelines, you have total control over which app and versions you want to publish and at what stage in the deployment pipeline. You don’t have automatic deployment of app contents.
Items or Workspace Permissions
To maintain robust security policies tailored to each stage of the deployment pipeline, workspace or item permissions are set independently in each deployment stage.
Refresh Schedules
To ensure that there are no unwanted refresh loads in sensitive environments, such as the production environment, each stage in a deployment pipeline has its own refresh frequency. Thus, any scheduled data refresh on one stage is not inherited at other stages.
Data Source Credentials
Data source credentials reconfiguration must be completed at each stage to prevent accidental credential sharing between environments in a deployment pipeline. This also helps to ensure enhanced data security.
Endorsements
During deployments, any endorsement labels you have in one stage do not automatically deploy to the next stage. This ensures that the integrity of endorsed content is maintained since you need a fresh review and approval process at each environment.
Folders
Folders in a workspace are, by default, not deployed during the deployment process, unless they contain at least one deployment item.
If you have a folder in one stage and it is not deployed to the next stage, it is most likely because you don’t have items in the folder yet (an item that is a deployment item).
Microsoft 365 Groups
Currently, you cannot leverage Microsoft 365 groups as usernames for deployment pipeline access permissions as Admins.
We can only have Admin access to Deployment Pipelines, and this admin access cannot be assigned to a Microsoft 365 group, as you could do in a typical workspace. You can only use the username of the individual you need to grant access to.
Next Steps
