What it does

Pipelines are in-product deployment automation. An admin links a set of environments to a pipeline held in a host environment, and makers then deploy their solution from inside their development environment with a few clicks — export, import, connection and variable configuration all orchestrated by the platform.

Key facts

• The pipeline definition lives in a host environment. Microsoft manages a default platform host, or you can run your own. One environment can't be attached to two hosts.
• Deployment environments must be Managed Environments; the host and developer environments needn't be. From February 2026 Microsoft began enabling Managed Environments automatically on pipeline targets that weren't already set.
• Solutions are exported once, when the maker submits the request, and the same artefact moves through every stage in order. The system blocks tampering, so nothing can bypass a QA stage.
• Only managed solutions are deployed to non-development targets. Unmanaged versions are also exported and stored in the host as backups.
• Default import behaviour is Upgrade without Overwrite customizations, and you can't currently choose update versus upgrade.
• Approvals come via delegated deployments. A stage can deploy as a service principal or as the stage owner, and an OnApprovalStarted cloud flow in the host drives the approval, calling the UpdateApprovalStatus unbound action with 20 for approved and 30 for rejected.
• The deploying identity owns deployed objects — the requesting maker for standard deployments, the delegate for delegated ones.
• Pipelines can't deploy across tenants. Cross-geo deployment needs the Cross-Geo Solution Deployments setting turned on in the host.
• One solution per deployment; no multi-solution deployments. Rollback to a previous version is possible if the redeploy setting is enabled.
• Runs can also be driven from the Power Platform CLI via pac pipeline.

When to use / skip

Pipelines are the right default for most clients. If the organisation doesn't already have an Azure DevOps or GitHub practice and someone competent to own it, in-product pipelines will give them governed deployments in an afternoon rather than a fortnight, and it's a Microsoft-supported product feature rather than YAML somebody wrote and left. Reach for full DevOps when you need multi-tenant deployment, branch-based builds, code components with a real build step, or multi-developer isolation on the same solution — pipelines currently assume a single development environment per solution. The two aren't exclusive; extending pipelines to call DevOps is a supported pattern.

Configuration decisions

• Microsoft's platform host versus your own host environment, and whether it shares an environment with the CoE toolkit.
• Whether stages are delegated, and if so whether the delegate is a service principal or a named stage owner — noting stage owner delegates can't deploy solutions with OAuth connection references.
• Which stages need approval and who approves, since the approval flow is yours to build.
• Whether sharing requests are allowed, letting requestors nominate security groups for access to deployed objects.
• Retention, via bulk delete jobs in the host, because run history and stored artefacts accumulate.

Gotchas

• Pipelines only appear in unmanaged solutions in a linked development environment. They aren't visible from the default solution, a managed solution, or a target environment.
• Pipelines don't publish unmanaged customisations before export. Unpublished changes silently don't ship, so publish as you save.
• Approvals sit pending forever if the approval flow is broken or was never built. Delegated deployments do not self-approve.
• Sharing during deployment only applies the first time an object reaches a target. You can't update sharing on later versions, so pick the right security group on the first release.
• Connection references with no existing value in the solution or the target can't be populated during deployment.
• The delegate must be an owner of the enterprise application in Microsoft Entra ID, not just the app registration. That error message catches nearly everyone once.

Consultant notes

• Lead with pipelines for citizen-heavy estates and position them as guided change management. Clients hear "governance" and stop asking for a full DevOps build they won't maintain.
• Set up delegated deployment with a service principal for production early. Deploying as the requesting maker means makers own production objects, which is rarely what the client actually wants.
• Warn that Managed Environments are required on targets, and that this is a licensing conversation — premium use rights are needed for those environments.
• The single-development-environment constraint is the one that ends the conversation for larger fusion teams. Establish team size and working model before you commit to an approach.

---

Worth revisiting once flow groups, multi-solution deployment or multi-dev isolation ship — several of these constraints are listed as planned.