Power Platform Pipeline Extensibility Changes Where Your ALM Logic Actually Lives

Solution architect reviewing an abstract Power Platform pipeline deployment diagram with an approval gate on an office monitor at dusk

Every Power Platform admin who has rolled out native pipelines has run into the same wall eventually. The tool is genuinely good at the thing it was built for: letting a maker click “Deploy” and move a solution from development to test to production without learning Azure DevOps YAML or touching a service connection. What it has never let you do, until recently, is put anything of your own between that click and the deployment itself. No custom validation before export. No compliance check before the artifact lands in production. No way to route the actual deployment through a service principal instead of the requester’s own credentials. If your organization needed any of that, the answer was to abandon native pipelines and rebuild the whole thing in Azure DevOps or with the community powerplatform-actions GitHub Action, which meant losing the low-friction maker experience that was the point of adopting pipelines in the first place.

Microsoft’s new Power Platform pipeline extensibility closes that gap, and it is worth understanding closely before you turn it on, because the way it is built shapes what kinds of governance logic actually belong there versus what still belongs in your existing CI/CD stack.

What pipeline extensibility actually adds

The mechanism is Dataverse business events. Power Platform pipelines now emit a defined set of events at each stage of a deployment, and a Power Automate cloud flow sitting in the pipelines host environment can subscribe to those events using the ordinary “When an action is performed” trigger from the Dataverse connector, filtered to the Power Platform Pipelines category. There are seven distinct trigger actions you can hook: OnDeploymentRequested, OnApprovalStarted, OnApprovalCompleted, OnPreDeploymentStarted, OnPreDeploymentCompleted, OnDeploymentStarted, and OnDeploymentCompleted. OnDeploymentRequested fires for every deployment regardless of configuration, and it is also the event a pre-export validation flow hooks into. The approval and pre-deployment pairs only fire at all if you have explicitly enabled the corresponding extension on that pipeline stage, so a flow subscribed to OnPreDeploymentStarted simply never triggers on a stage that hasn’t turned that gate on.

Abstract illustration of a deployment pipeline with connected stage nodes and a glowing approval gate checkpoint

Three gated extension points sit on top of those events, and each one solves a different problem rather than being interchangeable flavors of “add a step.”

Pre-export step required

This is the earliest gate. It runs when a maker submits a deployment request, before the solution is even exported from the development environment, and Microsoft explicitly restricts it to the first stage of a pipeline. That restriction matters more than it looks: once a solution is exported, the pipelines host stores the managed and unmanaged artifacts and promotes that exact same artifact version through every downstream stage. You cannot re-validate or re-export at stage two. Whatever checks you want to run against the source solution, whether that is a naming convention audit, a check for unmanaged customizations, or a call out to an internal change-approval system, have to happen here or not at all.

Is delegated deployment

This extension solves a different problem: identity. Without it, a deployment runs under the requesting maker’s own credentials, which means that maker needs write access to the target environment, something plenty of organizations are uncomfortable granting to anyone below an admin for a production environment. With delegated deployment enabled, the actual deployment executes under a service principal instead, provided the pipeline stage owner is configured as an owner of that service principal in Microsoft Entra ID. A maker can request a production deployment, get it approved, and never hold standing access to production at all. For any organization that has been quietly working around this by granting temporary System Administrator roles before a release and revoking them after, this is the fix that was missing.

Pre-deployment step required

This is the last gate, sitting after approval but before the deployment itself actually runs. This is where a final compliance check, a change-freeze lookup, or a notification to a service desk system belongs, since by this point the deployment has already been approved and you are deciding only whether to let it proceed right now.

Wiring a flow to it

The implementation pattern is consistent across all three extension points. You build a cloud flow, in the pipelines host environment specifically, not in the source or target environment, using the Dataverse “When an action is performed” trigger. You can scope the trigger with a condition against the output parameters, most commonly DeploymentPipelineName or DeploymentStageName, so that a single environment does not end up running every organization’s validation logic against every pipeline. Inside the flow you run whatever logic you need, whether that is a call to an external API, an approval step, or a lookup against a governance table, and then you close the loop with an unbound Dataverse action: UpdatePreExportStepStatus or UpdatePreDeploymentStepStatus, setting the status to 20 for complete or 30 for rejected. A rejected status fails the deployment outright rather than leaving it hanging. Microsoft ships two sample managed solutions, Pipelines Extensibility Samples and Delegated Deployment Samples, that are worth installing into a sandbox before writing anything from scratch, since they cover the trigger and action wiring in a working state rather than leaving you to reverse-engineer the output parameter names from documentation alone.

Where this still falls short

None of this replaces a pro-code CI/CD pipeline, and it is not trying to. The GitHub Actions and Azure DevOps paths for Power Platform still own the things extend pipelines does not touch: source-controlled solution unpacking, automated build artifacts, and static analysis through the solution checker as part of a pull request gate rather than a deployment-time check. What extend pipelines is actually good at is inserting governance and identity control into the maker-facing deployment experience without forcing every citizen developer through a developer-grade toolchain. That is a narrower job, and treating it as a replacement for real CI/CD is the most common mistake I would expect teams to make with it.

The rollout itself is also worth flagging before you plan around it. As of this writing, Microsoft describes the extensibility features as being rolled out gradually across regions, and existing pipelines customers may need to update the Power Platform pipelines application through the admin center before any of these extension points even appear as configurable options. If you check a production tenant and do not see pre-export or pre-deployment settings on a pipeline stage, that is very likely a rollout or update-application issue rather than a misconfiguration on your end, and it is worth confirming with a support ticket before spending time debugging a flow that was never going to fire.

A few operational limits are worth building into your rollout plan from day one. Personal pipelines created inside make.powerapps.com cannot be extended at all, so any governance requirement has to be enforced through admin-managed pipelines rather than personal ones if extensibility is part of the plan. Makers retain the ability to cancel a pending deployment request, but only up until the final deployment step actually begins, so a long-running pre-deployment check is not a safe place to also expect cancellation to work cleanly. And because the exported artifact is immutable across all downstream stages, any pre-export validation logic needs to be strict enough to catch problems before that first export, since there is no second chance to reject the same artifact further down the pipeline.

For architects who have been asking Microsoft for a middle ground between no governance hooks at all and abandoning native pipelines for full Azure DevOps, this is that middle ground. At Routeget Technologies, this is the kind of gap our Power Platform ALM engagements have historically had to close with custom Azure DevOps pipelines, so a native option worth building a proof of concept around is a welcome addition. It is worth testing against a sandbox pipeline now, both to get ahead of the regional rollout and to work out which of the three extension points actually maps to a real control gap in your current deployment process, rather than instrumenting all three reflexively the day they become available in your tenant.

#PowerPlatformPipelines #ALMGovernance #DataverseBusinessEvents #DelegatedDeployment #PowerAutomate #EnterpriseAutomation

Power Platform License Enforcement Has a Deadline: February 2027

IT director and finance leader reviewing a software licensing compliance dashboard together in an office

A Power Platform administrator at a mid-size manufacturer got an odd notice in her Microsoft 365 message center in March. It referenced managed environments, a governance feature she associated with premium licensing decisions her CIO had deliberately deferred two budget cycles in a row. She assumed it was routine noise and archived it. Six months later, the same governance feature had been switched on for a dozen production environments without a single approval meeting, because those environments happened to be deployment targets in the organization’s new Power Platform pipelines setup. Nobody had connected the dots between an ALM modernization project and a licensing enforcement clock that started ticking the moment it went live.

That disconnect is becoming common, and it points to a real Power Platform license enforcement deadline that CIOs and IT directors should be treating as a budget line item rather than a footnote in an admin center notification. Microsoft has been quietly retiring the ALM Accelerator for Power Platform, the free, GitHub-based reference implementation many organizations used to bolt source control and deployment automation onto Azure DevOps. In its place, Microsoft is steering everyone toward Pipelines, the native, in-product ALM experience built directly into the Power Platform admin center. The pipelines feature itself is a genuine improvement for most organizations. The licensing mechanics it triggers are the part that deserves scrutiny before anyone signs off on the migration.

Why the ALM Accelerator Is Going Away

The ALM Accelerator was never meant to be permanent. Microsoft built it as a canvas app and Azure DevOps extension pairing, a reference pattern for makers who wanted Git-backed source control and staged deployments without hiring a professional DevOps team. Microsoft’s own documentation now marks it deprecated: no new features, and issues raised against it are no longer reviewed or fixed. The stated successor is Pipelines, described in Microsoft’s guidance as the strategic, in-product experience for maker-initiated application lifecycle management, extensible into Azure DevOps or GitHub when a team needs deeper customization.

For a lot of teams, that is a reasonable trade. Pipelines can be configured in minutes rather than the days or weeks a hand-built Azure DevOps release pipeline typically takes, and it comes with pre-validation, staged approvals, and automatic solution backups out of the box. The tradeoff is that Pipelines requires its non-host target environments, meaning the QA and production environments a solution deploys into, to be managed environments. Development environments are exempt, and the pipeline host itself does not have to be managed, but everything downstream of it does.

IT director and finance leader reviewing a software licensing compliance dashboard together in an office

The Auto-Enablement Nobody Voted On

Here is where the administrator’s ignored notice becomes relevant. Microsoft’s documentation states plainly that starting in February 2026, it began enabling managed environments automatically for any pipeline target environment that was not already configured that way. Tenant admins can opt into a setting under Deployments, Settings in the Power Platform admin center that converts pipeline targets to managed environments proactively, and Microsoft recommends doing so. But the underlying enforcement is not contingent on that opt-in. If a solution is deployed through a pipeline into an unmanaged production environment, Microsoft’s rollout will convert that environment regardless of whether an admin ever flipped the setting.

That matters because managed environments are not a purely technical governance toggle. They carry a licensing dimension that most conversations about ALM modernization skip entirely.

The Licensing Dimension Most ALM Conversations Skip

Managed environments themselves do not cost extra on top of the right license. They come bundled as an entitlement with standalone Power Apps Premium, Power Automate Premium, Copilot Studio, Power Pages, and most Dynamics 365 licenses, along with pay-as-you-go meters for per-app and Copilot Studio consumption. That sounds harmless until you account for how many production apps in a typical enterprise are actually running on seeded or included rights rather than a standalone license: a Power Apps use right bundled into an Office 365 plan, or Power Automate capability included with a Dynamics 365 Pro license and scoped only to that application’s context. Those included rights were never built to satisfy managed environment licensing requirements on their own, and Microsoft’s own FAQ language on the topic notes that Power Apps or Power Automate capability tied to a Dynamics 365 Pro license is meant to be used only within that licensed application, not as a general-purpose citizen development platform.

Managed environments carry an autoclaim policy that automatically assigns the correct license to a user who accesses an app there, provided the tenant has license capacity to draw from. Autoclaim solves the paperwork problem of manually assigning licenses one user at a time. It does not solve the budget problem of simply not owning enough qualifying licenses to autoclaim against, and it does nothing for a user whose only access to Power Apps or Power Automate comes through a seeded right that was never designed to extend into a managed, governed production environment.

Abstract illustration of a countdown clock merging with a network of cloud environment nodes, some locked and some unlocked

The Power Platform License Enforcement Timeline You Are Already Inside

This is not a distant, hypothetical deadline. Microsoft’s published timeline shows administrative notifications through the Microsoft 365 message center and Power Platform admin center beginning in March 2026. In-app notifications aimed directly at end users without an appropriate license started in June 2026, following a staged escalation: an informational message on day one, a warning after seven days, and an error state after fifteen, each urging the user to request a license from an admin. The hard stop lands in February 2027: users who still lack an appropriate license at that point are blocked from opening the app entirely, shown a standard message telling them they need a Power Apps license to use it. Apps are not deleted and access resumes automatically once a qualifying license is detected, but for that window, whatever workflow depended on that app simply stops working for that user.

Given today’s date, that means the notification phase is already well underway inside most tenants that run pipelines against production environments, and the enforcement date is now closer than most annual license renewal cycles.

What This Means for the Business Case

None of this is a reason to avoid Pipelines or to keep patching together an already-deprecated ALM Accelerator deployment. The practical response is to treat the license audit as part of the ALM modernization project plan rather than as an afterthought that surfaces after go-live. That means pulling a current list of every user who accesses production apps sitting in, or scheduled to sit in, a pipeline-managed environment, and checking each one against a standalone qualifying license rather than assuming a Microsoft 365 or Dynamics 365 seat covers it. It means asking whether apps currently running on included, scoped rights actually need to move to standalone Premium licensing, get rearchitected to stay within their original licensed application’s context, or get retired if nobody can justify the cost. And it means giving finance and procurement enough lead time to true up license counts well before February 2027, rather than discovering the gap when a plant floor supervisor gets locked out of a production app and escalates it as an outage.

Organizations that have gone through this kind of ALM transition tend to find the technical migration to Pipelines is the easy part. The harder, more valuable work is the license and governance audit that should have accompanied it from the start, which is usually where firms like Routeget Technologies get pulled into these engagements: less to configure a pipeline, more to make sure the environments behind it do not quietly turn into a compliance problem eleven months later.

#PowerPlatformPipelines #ManagedEnvironments #ALMGovernance #PowerPlatformLicensing #LicenseComplianceAudit #EnterpriseGovernance