The One Switch That Decides Whether Your Pipelines Are Governed

Here is the uncomfortable question to open with. If a maker in your tenant deployed a solution to a production environment last week using pipelines, would you know? Would you know which host processed it, who approved it, and whose identity owns the objects that landed there?

For most tenants the honest answer is no, and the reason is that pipelines do not wait for you to adopt them. The platform host is tenant wide and available by default, and makers can create personal pipelines without administrator intervention. Pipelines are not a capability you switch on. They are a capability you either govern or do not.

This article covers what pipelines actually are, the host decision that determines whether they are governed, the artifact model that makes them a genuine control rather than a convenience, and the limitations worth knowing before you commit an organization to them.

What pipelines are trying to solve

Microsoft’s stated goal for pipelines is democratizing application lifecycle management: bringing ALM automation and continuous integration and delivery into the service in a form that is approachable for makers, admins, and developers alike. That framing is worth taking seriously, because it explains most of the design decisions that follow, including the frustrating ones.

The problem pipelines address is not that ALM tooling did not exist for Power Platform. Azure DevOps, GitHub Actions, and the ALM Accelerator all did the job. The problem is that every one of them required a person who understood export, unpack, source control, build definitions, and deployment settings files. In most organizations that person exists on one or two teams, and every other team ships by exporting a solution manually and importing it somewhere else.

Pipelines target that gap. Administrators configure deployment pipelines in minutes rather than days. Makers deploy from inside their development environment with a few clicks and no prior ALM knowledge, and citizen developers tend to experience the result as a guided change management process rather than as tooling. Professional developers can run the same pipelines from the Power Platform CLI and extend them where needed.

The governance value follows from the adoption value. A control that only the advanced teams use is not a control. Pipelines are interesting to administrators mainly because they are plausible for the teams that would otherwise be importing solutions by hand.

The host decision is the governance decision

Everything that matters about pipeline governance flows from one choice: which host your pipelines run in.

The platform host

This is the tenant wide default, and it can be configured by makers. A maker in a development environment that is not already associated with a custom host can create a lightweight personal pipeline themselves.

Two design details are worth crediting here, because they close the obvious objections. First, makers do not receive elevated environment access as a result. The target environment picker is filtered to environments the maker can already import to, so a personal pipeline cannot reach anywhere the maker could not reach manually. Second, all personal pipelines are stored in the platform host, which administrators can see. Microsoft’s position is that this makes maker self-service ALM visible rather than invisible.

There is also a licensing quirk in the platform host’s favour. Data consumption in the platform host does not count against your plan, because pipelines data for the platform host is stored in Power Platform infrastructure rather than in a customer environment. It remains within your tenant and accessible to administrators. Capacity does apply to a custom host, which is a normal customizable environment.

So the platform host is genuinely reasonable as a default. The problem is not that it is dangerous. The problem is that it is a decision that gets made by not making it, and most administrators discover their tenant already has pipeline activity in it rather than having planned for that.

The custom host

A custom host is an environment where you install the Power Platform Pipelines application, and it is how administrators centrally govern citizen led and pro dev led projects. The critical behavioral difference is that custom hosts do not grant pipeline creation access by default. The Deployment Pipeline Default role is not assigned to anyone, so the personal pipeline creation experience is simply not visible in environments associated with a custom host.

That inversion is the whole point. In the platform host, access is the default and restriction requires action. In a custom host, restriction is the default and access is granted deliberately, either through the Deployment Pipeline Default role or by adding users to the Deployment Pipeline Maker team.

Hosts do not conflict with each other. An environment already associated with a custom host cannot be picked up by a maker creating a personal pipeline, and an environment can only be associated with one host at a time. Where an environment is already linked elsewhere, administrators can use Force Link to override the existing association.

The single switch worth knowing about

If you take one configuration action from this article, it is this one. In the admin center under Deployment, then Settings, the Use a custom pipelines host option sets one default host for the entire tenant. It replaces personal pipelines, meaning administrators control who can access pipelines and makers can no longer create their own in the platform host. The setting is only visible when the Platform host is selected in the host picker.

This is a genuine fork rather than a tuning knob, and it deserves a deliberate decision rather than a default. Choosing the platform host means you have decided that maker self-service ALM with administrator visibility is the right posture, which is a defensible position and better than most organizations have today. Choosing a custom host means deployment is a governed service with an owner. What is not defensible is not knowing which one you are running.

The artifact model is why this counts as a control

Most deployment tooling is a convenience wrapper around operations a determined person could perform manually. Pipelines are not, and the reason is worth understanding because it is the strongest argument you have when talking to audit and compliance stakeholders.

When a maker selects Deploy, the solution is exported at that moment, and the same solution artifact is what gets deployed. The system does not re-export the solution for subsequent stages, and it prevents tampering or modification of the exported artifact. The same artifact must pass through pipeline stages in sequential order.

The consequence, stated plainly by Microsoft, is that customizations cannot bypass QA environments or your approval processes.

That is a materially stronger guarantee than most hand rolled ALM processes provide, and it is stronger than what many teams achieve with general purpose CI/CD tooling where a build can be re-run against a changed source. If your organization has ever had to answer the question of whether the thing running in production is the thing that was tested, pipelines answer it structurally.

Two supporting behaviors reinforce this. Both managed and unmanaged solutions are automatically exported and stored in the pipelines host for every deployment, which gives you a backup you did not have to configure. And customizations along with an audit log are saved automatically and remain accessible. For an organization that has been meaning to build deployment auditing and never got to it, this arrives for free.

There is a recovery story attached as well. The import from pipelines host capability lets users recover unmanaged and managed solutions from past deployments, which matters when a solution is accidentally lost and needs restoring to a development environment. Administrators can alternatively download the unmanaged solution directly from the deployment history record.

Delegated deployments: getting makers out of production

By default, the deploying identity is the requesting maker, and the maker owns the deployed solution objects. That is fine for a test environment and awkward for production, because it means the maker needs sufficient rights in the production environment for the deployment to work at all.

Delegated deployments change that. When a pipeline stage is marked as a delegated deployment, it deploys as the delegate, a service principal or the pipeline stage owner, instead of as the requesting maker.

The setup involves creating an enterprise application in Microsoft Entra ID, adding it as a server to server user in the pipelines host and each target environment, and assigning it the Deployment Pipeline Administrator role in the host plus System Administrator in the targets. Lower permission roles cannot deploy plug-ins and other code components, which is a common cause of confusing partial failures.

One security constraint catches people out and is worth flagging early. Anyone enabling or modifying service principal configurations in pipelines must be an owner of the enterprise application in Entra ID. Being an owner of the app registration is not the same thing, and Microsoft calls this out specifically because the resulting error message points at a condition most people assume they already satisfy.

Approvals are where the control actually lives

All delegated deployments stay pending until approved. The approval mechanism is a cloud flow in the pipelines host using the OnApprovalStarted trigger, ending in a Dataverse unbound action called UpdateApprovalStatus. That action has to be called by the delegate’s own connection, whether that is the service principal or the stage owner, which is the most common reason a correctly built approval flow fails.

Because the approval is a flow rather than a fixed dialog, you can insert whatever your organization requires: a change advisory board notification, a ticket reference check, a freeze window test. Administrators can also review and approve deployment requests directly on the admin center Deployment page.

Sharing during deployment, and the trap inside it

Delegated deployments with service principals can also handle access assignment. Requestors can specify which security groups should access deployed objects, the request is approved or rejected along with the deployment, and pipelines assigns permissions automatically using the deploying service principal’s identity. Security roles, canvas apps, and cloud flows are supported, with Copilot sharing available depending on region. Pipelines assign the minimum privileges required to run apps and flows.

This removes a genuinely tedious administrative task. It also introduces a constraint you must design around: sharing is available the first time an object is deployed to the target environment, and cannot be updated when new versions are deployed. Individual user sharing is not supported.

The practical implication is that your first deployment of any object needs to specify the right security group, because that is your one chance to set it through this mechanism. Manage ongoing access by changing security group membership rather than by changing the sharing configuration. If your identity governance is mature, that is the correct pattern anyway. If your organization tends to share resources with named individuals, this will feel restrictive until the day it saves you.

Microsoft is direct that approvers carry real responsibility here, since approving a deployment triggers automatic permission assignment. Treat the approver role as a security role, not an administrative formality.

The managed environments requirement and its licensing tail

All target environments used in a pipeline must be enabled as managed environments. The host itself should be a production environment but does not have to be managed, and development environments are not required to be managed either, which means developer plan environments work for development and testing. Licenses granting premium use rights are required for all managed environments.

Microsoft’s own example configuration makes the shape clear.

Environment purpose	Environment type	Standalone license required
Host	Production	No
Development	Developer	No
QA	Developer	No
Production	Production	Yes

This requirement is no longer advisory. Starting February 2026, Microsoft began enabling managed environments for pipeline target environments that were not already enabled, with affected tenants notified through the Microsoft 365 message center. That notification is generated where environments are not managed, are the target of a pipeline, and were used for a deployment in the last six months, and it lists the specific environments needing action.

Two details deserve emphasis. First, the automatic enablement setting under Deployment then Settings is opt in and separate from the enforcement. Turning that setting off does not exempt you from the enforcement, because the notification is about environments you have already deployed to. Second, and this is the part that surprises people: managed environments come with an autoclaim policy applied automatically, which means users who access apps in those environments automatically receive the necessary licenses. Microsoft’s guidance is to ensure you have appropriate license capacity in the tenant to use autoclaim.

So the sequence to be aware of is: pipeline targets become managed environments, managed environments carry autoclaim, and autoclaim consumes license capacity as users touch apps in those environments. There is no expected disruption to end users or their applications from the enablement itself. The consideration is capacity planning, not availability.

To find your exposure, go to Deployment, then Pipelines, then Run History, select a host, and change the filter to the last 180 days. Environments listed under Target require managed environments. Check every host if you have more than one, since deployment data is not aggregated across hosts.

What the admin center gives you

The Deployment page in the admin center is where administrators see tenant wide deployment activity, approve requests, and troubleshoot. Select a host and you can view all its pipelines and deployment history, filterable up to the last 365 days.

Run history shows start and end times, the pipeline used, the source development environment, the target environment, status, and the solution name and version deployed. A dedicated Failed deployments view helps identify problems, and failed deployments can be retried from the details panel where the operation was a deploy.

Settings are managed separately for each host and cover four things worth reviewing: automatic conversion of pipeline environments to managed environments, solution deployments across regions, whether makers can import shared solution deployments, and the custom pipelines host switch discussed earlier.

The cross region setting deserves specific attention if you operate under data residency constraints. With it disabled, the host and all associated environments must be in the same geographic location, and a host in one geography cannot manage environments in another. Where a tenant administrator wants to prevent cross geography solution deployments, the guidance is to use separate hosts per region. Enabling the setting explicitly enables data to be shared across geographic regions within your tenant, which is a decision that belongs with your data protection stakeholders rather than with whoever is configuring the pipeline.

Note that the Deployment page does not yet carry every capability available in the Deployment Pipelines Configuration app, so advanced configuration, richer run history, and report generation still route through the model driven app in the host environment.

Limitations to know before you commit

Pipelines are deliberately simpler than general purpose CI/CD, and simplicity has a price. These are the constraints most likely to matter, drawn from Microsoft’s own documentation rather than from complaints.

One solution per deployment. Multiple solutions cannot be deployed at once. You submit a separate deployment for each, though the same pipeline can serve multiple solutions. If your release unit is a set of interdependent solutions, this is friction you will feel every release.
One development environment per solution. The current implementation uses a single development environment for a given solution, so multi developer teams working in isolated development environments are not accommodated by pipelines alone.
Import behavior is fixed. Advanced import behaviors such as update versus upgrade cannot be specified. Pipelines default to upgrade without overwrite customizations.
No unmanaged deployment. Unmanaged solutions cannot be deployed, which is correct practice for nondevelopment environments but rules out some legitimate development to development scenarios.
No cross tenant deployment. Microsoft recommends Azure DevOps or GitHub for that scenario.
Publishing is not automatic. Pipelines do not publish unmanaged customizations before exporting the solution. Publish objects as you save them, or discover the omission at deployment time.
Connection reference limits. Connection references without a value in the solution or target environment cannot be updated during deployment. Once a value has been deployed, it can be updated subsequently.
Rollback depends on a setting. Redeploying previous solution versions requires the relevant pipeline setting to be enabled. With it disabled, only higher solution versions can be deployed, and the workaround involves downloading the artifact, incrementing the version in solution.xml, and importing manually.
Power BI content is not supported. Power BI dashboards and datasets in preview are not currently supported in pipelines.
Limited first party extensibility. The first party deployment pipeline app and tables cannot be customized, though intentional extension hooks exist for customizing pipelines logic.

None of these are fatal for the scenario pipelines target. Several of them are disqualifying for a large program with interdependent solutions and multiple developers per solution, which is exactly why the next section exists.

Pipelines, Azure DevOps, and the ALM Accelerator

This comparison generates more argument than it deserves, largely because it is usually framed as a choice. Microsoft’s own guidance is to use pipelines for core deployment functionality and extend them to integrate with other CI/CD tools where needed, and notes that the workloads required in those tools often become less complicated to maintain when used together.

On the ALM Accelerator specifically, Microsoft’s framing is that both offer valuable capabilities and the teams work together closely. Pipelines are more simplistic and can be set up and managed with less effort, requiring no access to other products or technologies. The Accelerator is sometimes a better fit for more advanced scenarios. The fundamental difference offered is not functional: pipelines are an official product feature designed, engineered, tested, maintained, and supported by Microsoft product engineering, and built into native product experiences.

For an administrator, the practical reading is this. Pipelines are the right default for the long tail of solutions across your organization, which is where most of your ungoverned deployment activity actually lives. Your two or three advanced programs with source control, branching, and automated testing will keep their existing tooling and should. The mistake is treating the advanced programs’ requirements as the standard the whole tenant must meet, because that is how organizations end up with excellent ALM on three solutions and manual imports on two hundred.

A governance checklist

Open the Deployment page and review every host, including the platform host. Establish what is already running before deciding anything.
Filter run history to the last 180 days and list every target environment. These are your managed environment obligations.
Confirm license capacity for autoclaim before pipeline targets convert to managed environments.
Decide the host question deliberately. Platform host with visibility, or custom host with granted access. Write down which and why.
If you choose a custom host, set Use a custom pipelines host so the choice applies tenant wide rather than per project.
Configure delegated deployments with a service principal for every production stage. Verify the person configuring it owns the enterprise application in Entra ID, not just the app registration.
Build the approval flow with the OnApprovalStarted trigger and confirm UpdateApprovalStatus uses the delegate’s connection.
Decide your cross region posture. If data residency binds you, use separate hosts per geography rather than enabling cross region deployments.
Brief your approvers that approving a deployment assigns permissions automatically, and that the first deployment of an object sets its sharing permanently.
Configure bulk delete jobs in the Dataverse pipelines host if you need a retention policy on pipelines data.
Review whether the default deployment pipeline rule for environment groups fits your structure, so that new environments inherit a pipeline association rather than needing one added.

Closing thought

The interesting thing about pipelines is not the feature list. It is that Microsoft made an opinionated bet: that the ALM problem in Power Platform is an adoption problem rather than a capability problem, and that a simpler tool used by everyone beats a powerful tool used by the advanced teams.

That bet shows up in every limitation listed above. One solution per deployment and one development environment per solution are not oversights. They are the cost of a tool a citizen developer can use without training, and they are why pipelines reach the teams that would otherwise be exporting solutions to their desktop.

For an administrator, the governance question is not whether pipelines are sophisticated enough. It is whether the deployments happening in your tenant right now pass through anything at all. Go and look at the Deployment page. The answer is already there.

Sources

Pipelines capabilities and admin center navigation change regularly. Verify current behavior in Microsoft Learn and in your own tenant before acting on configuration guidance here.