What it does

In-product solution deployment. An admin links a set of environments to a pipeline once, and makers then deploy from inside their unmanaged solution with a few clicks — no export, no download, no manual connection setup in the target.

Key facts

• Pipelines deploy solutions plus target configuration: connections, connection references and environment variables. They don't move data in Dataverse tables.
• Managed solutions only. Unmanaged deployment to non-development environments isn't supported, though both managed and unmanaged builds are exported and kept in the pipelines host automatically.
• The solution is exported once, when the maker presses Deploy, and the same artefact passes through every stage in order. The system blocks tampering, so nothing can bypass a QA stage.
• Deployments are pre-validated against the target — missing dependencies, connections and environment variables surface before the import starts.
• Development environments don't need to be Managed Environments and can run on the Developer plan. The pipelines host should be a production environment but doesn't have to be managed. Every other environment in the pipeline must be a Managed Environment, and Managed Environments need licences granting premium use rights.
• From February 2026 Microsoft began enabling Managed Environments on pipeline target environments that weren't already enabled, notified through the Microsoft 365 message centre.
• Approvals come from delegated deployments, where a service principal or delegated user performs the deployment after sign-off.
• Default import behaviour is Upgrade without Overwrite customisations, and you can't currently change it.
• One solution per deployment. You can reuse the same pipeline for multiple solutions but you can't batch them into one run.
• Cross-tenant deployment isn't supported. Cross-geography works only if the Cross-Geo Solution Deployments setting is on in the host.
• Rollback to a previous solution version works if the redeploy setting is enabled; otherwise only higher versions can go in.
• Power BI dashboards and datasets are in preview and aren't currently supported in pipelines.

When to use / skip

For most clients this is now the right default. The setup is measured in minutes rather than days, the maker experience is genuinely simple, and pre-validated connections and environment variables remove the manual post-deployment fiddling that used to eat an afternoon per release. Reach for Azure DevOps or GitHub instead when you need cross-tenant deployment, multiple developers working in isolated environments on the same solution, or a build process that compiles plug-ins and PCF controls. The two aren't exclusive — pipelines can be extended and called from CI/CD tooling, and that combination is usually less work to maintain than doing everything in DevOps.

Configuration decisions

• Which environment is the host, remembering it can't also be a development environment and shouldn't normally be the default environment.
• How many stages: dev to production, or dev to QA to production, or more. Stages are sequential and can't be skipped, so add them deliberately.
• Whether deployments to production go through delegated deployment with approval, which is the control the risk function will ask about.
• Whether target environments are converted to Managed Environments automatically, and whether the licensing to support that is in place.
• Whether service principals are used per pipeline and per stage, or one identity does everything.
• Whether previous-version redeployment is enabled, which is your rollback story.

Gotchas

• The Managed Environments requirement is a licensing conversation disguised as a technical setting. Clients discover it after the pipeline is designed, and it can change the shape of the environment strategy.
• Pipelines don't publish unmanaged customisations before exporting. Unpublished changes silently don't ship, so publish as you go.
• A pipeline only appears in environments linked as development environments. If it's missing, the environment type in the pipeline configuration is usually wrong.
• Solution ownership in the target goes to the deploying identity — the maker for standard deployments, the service principal for delegated ones. That matters for anything with owner-based security.
• One environment can't belong to two hosts. Moving it means adding it to the new host, then deleting the record from the old one and re-testing.
• Multi-developer teams working in separate environments on one solution aren't supported by the current implementation.

Consultant notes

• Lead with the governance story, not the convenience one. "The same artefact passes through every stage and nothing can bypass QA" is the line that gets budget from a risk function; "fewer clicks for makers" is not.
• Check the Managed Environments licensing position before you design the pipeline, not after. It's the most common reason a pipeline design gets reworked.
• Set the expectation that pipelines and Azure DevOps aren't competing choices. Clients who think they must pick one often pick DevOps and then maintain far more YAML than the problem needed.
• If the client is running the CoE toolkit, the question of whether the pipelines host is the same environment will come up. It's a valid configuration; decide it on their policy rather than by default.

---

Worth revisiting after the next release wave, or if multi-solution and multi-developer support arrives.