Power Platform managed services: what running the estate involves after go-live

Power Platform managed services are the standing work that keeps apps, flows and agents running once the project that built them has gone. In practice that is nine responsibilities: environments and environment groups, data policies, capacity, licences, deployments through pipelines, backups, monitoring and alerts, Microsoft’s release and deprecation calendar, and the support cases Microsoft will and will not take. None of them has an end date, which is what separates a managed service from a project.

Most of that work now runs through the Power Platform admin center, and much of it only works on Managed Environments: custom alerts, the full set of recommendations on the Actions page, backup retention beyond seven days and environment group rules all need them. This article sets out what each responsibility involves as Microsoft documents it on 11 November 2026, where the jobs the retired CoE Starter Kit used to do have gone, and how a managed service differs from building the estate or reviewing its governance. Setting up the foundation before makers arrive is a separate job, covered in our Power Platform landing zone article.

Managed service, project or governance review: three different purchases

Three things are sold under similar names, and they answer different questions.

Our managed service vs project article sets out why the two are not interchangeable: a project delivers workload responsibilities, while the central platform responsibilities never complete. Power Platform makes the point concrete. Microsoft’s guidance on designating a Power Platform admin lists nine responsibilities for the role, from the governance framework and environment management through performance monitoring, user access and support to continuous improvement. Every one of them is continuous, and the same page asks for “regular reviews of the individuals with the Power Platform service admin role” to check each still needs it.

A governance review is different again. It decides what the controls should be, once. Our governance article and the landing zone article describe that kind of work. A managed service inherits those decisions and keeps them in force as the estate changes underneath them.

Not every estate needs one. Where a mature platform engineering function already handles governance, automated guardrails, environment lifecycle management and core telemetry, a broad horizontal retainer is redundant and wasteful, and the only useful commercial roles left are specialist escalation and discrete project spikes. The rest of this article is the list to test that against. If your own team already does all of it, a retainer buys duplication.

What a Power Platform managed service covers

The table below is our summary of Microsoft’s current admin documentation, not a Microsoft list. The last column matters more than it looks, because Managed Environments are licensed: Microsoft’s licensing page says that once you activate them, “all active usage requires one of these standalone licenses or pay-as-you-go meters”.

That last column decides what we will take on. We will not run an ongoing production SLA on an unmanaged Power Platform environment, because without Managed Environments there are no environment group rules, no custom alerts, no backups kept beyond seven days and, once Microsoft’s grace period ends, no pipeline deployments into it. We will take on an estate whose production apps sit in unmanaged environments, or in the default environment, but the first month is then a mandatory onboarding track: modelling the cost of the standalone licences Managed Environments require, and moving production into them.

The sections below take each in turn.

Environments, groups and data policies: the change desk

Changes to the boundary are the core of the change desk: a new environment, a connector someone needs, a group a new environment belongs in. Microsoft’s reactive governance guidance asks for an approval workflow for new environment requests, and says changes to data policies “should go through a formal approval process to maintain security and compliance.”

The reason is what a data policy change does to things already running. Per Microsoft’s data policies page, every app, flow and chatbot is re-evaluated after a change, and one that violates the policy is put “in to a suspended or quarantine state so that it can’t operate.” Enforcement is not instant either: “For the most extreme cases, the latency for full enforcement is 24 hours. In most cases, it’s within an hour.” Advanced connector policies are stricter, applying their allowlist “as soon as you save it (single environment) or publish it (environment group)”. A data policy edit is therefore a production change. It belongs in the same change process as a deployment, with the affected apps and flows identified before it is published, which is what inventory’s connector view is for (see the CoE section below).

Environment groups add a constraint the service has to work within. Per Microsoft’s environment groups page, they “can only contain managed environments”, a published rule is locked in every member environment, and “Per-environment exceptions aren’t currently supported.” An environment that needs different treatment needs a different group, so placing a new environment is a decision rather than a click. The group rules now reach well into operations, including Back-up retention, Release channel, Solution checker enforcement and a cost control on drawing from the tenant credit pool, so a rule change is a change for every environment in the group at once.

Retirement is the other half, and Power Platform does some of it on its own schedule. Microsoft’s environment cleanup page is plain that “You can’t turn off this cleanup mechanism.” It covers default, developer and Dataverse for Teams environments. An unmanaged developer environment is disabled after 30 days without activity and a managed personal one after 60, and either is deleted 15 days after that. The notices go to the environment’s system administrators and its creator, and to tenant administrators only once the environment’s own admins have left the tenant, so a service that does not watch those addresses learns about a deletion afterwards. Separately, unmanaged developer environments are being retired outright: per Microsoft’s important changes page, none can be created from 15 November 2026, existing ones are suspended from 15 December 2026 and deleted from 15 January 2027. The landing zone article covers what to do about them.

Capacity and licences: the monthly position

Three capacity currencies need watching, and each fails differently.

Dataverse storage. Microsoft’s capacity page describes an upcoming Dataverse storage validation, for tenants with no Dynamics 365 Finance and Operations environments or consumption, with rollout dates in the Message center, that escalates in stages. Notifications start when effective consumption passes 85%. When a tenant first goes over 100%, “Environment create, copy, restore, and recover operations are blocked.” After 30 days unresolved, affected sandbox environments go into administration mode; after 90, sign-in to them is blocked for everyone, administrators included. Production environments are not put into administration mode or disabled, but Microsoft adds that “Production work can still be affected when it depends on a blocked create, copy, restore, or recovery operation.” Restore is the one that matters most to a service: an estate over its limit cannot restore an environment until the overage is resolved or covered by a temporary capacity extension. Capacity can be allocated per environment, with daily email alerts when consumption reaches a set percentage of the allocation.

Copilot Credits. Copilot Studio agents run on Copilot Credits, pooled across the tenant and allocated to environments. Per Microsoft’s Copilot Credits capacity page, each environment can be set to draw on the tenant pool or bill a pay-as-you-go plan once its allocation runs out, and “If no overage source is enabled, the environment can consume only its allocated prepaid credits.” Admins can set a monthly limit per agent, with notifications as it nears the limit and a hard stop that turns the agent off. Microsoft warns that “Limits aren’t applied instantly”, and that an agent’s limit does not stop the agent flows it calls. Prices and enforcement are covered in Copilot Studio licensing.

AI Builder credits after 1 November 2026. Microsoft’s end of AI Builder credits page keeps existing seeded credits to the end of the contract term and active add-ons until they expire. After that, AI Builder features in Power Apps and Power Automate fall back to Copilot Credits, and “If no Copilot Credits are available, usage will be blocked.” So the dates that matter now are each renewal and each add-on expiry, not 1 November. Our AI Builder article covers the error messages and how to restart a stopped flow. For estates we run under managed services, AI Builder and Copilot Credits exposure is tracked against each subscription renewal and add-on expiry date, and the managed service runbook checks credit pool exhaustion against the renewals coming up.

Licences. Managed Environments turn licensing into an operational task. Microsoft’s licensing page says “Starting February 2027, an appropriate license is strictly required for a user to open an app in a managed environment.” Until then, unlicensed users see in-app notifications that move from informational to warning to error at seven-day intervals, and their requests land in the Power Platform admin center under Actions, then Recommendations, and in the Microsoft 365 admin center under Billing, Licenses, Requests. Microsoft’s report of users requiring licences counts only users who launched an app in the month selected, so a single month understates the gap; our managed environments licensing article explains why to take several months together. Microsoft’s licence consumption view, still in preview, adds purchased, assigned and used counts, where used means a licensed user who launched an app at least once in the last 90 days. Trial licences need a diary entry of their own, because in a managed environment they cover a user for 30 days only.

Deployments, backups and who owns production

The ALM process the project set up has to keep running after it, and two details in Microsoft’s pipelines overview decide how a service runs it.

The first is ownership. Asked who owns deployed solution objects, Microsoft answers: “The deploying identity. For standard deployments, the owner is the requesting maker. For delegated deployments, the owner is the delegated service principal or user.” A production estate deployed by makers is owned, object by object, by people who will eventually move on. Delegated deployments, which Microsoft describes as “approval based”, put an approval step in front of production and leave ownership with a service principal or a nominated user, which is the arrangement a managed service can stand behind.

In the Power Platform estates we take over after a project team leaves, the first thing to break is almost always an automated cloud flow tied to a departed contractor’s or project engineer’s personal connections rather than a service principal. Nobody in IT knows it has stopped until business users notice, two weeks later, that approvals or SharePoint syncs have quietly piled up, because the failure notifications are still going to a disabled mailbox.

The second is what a pipeline does not carry: “Pipelines, or solutions in general, don’t contain data stored within Dataverse tables.” Every deployment exports the solution and stores it in the pipelines host, so definitions can be redeployed, but data depends on backups. Microsoft is also enforcing the managed environments rule for targets: “Starting in October 2026, the admin deployment page notifies admins when pipelines deploy to unmanaged target environments”, and deployments to that target are blocked if managed environments are not enabled within 30 days, with one further 30-day extension available per environment.

Backups have limits of their own. Per Microsoft’s backup and restore page, system backups are kept for seven days by default, extendable to 28 days only for production managed environments, and “Backup and restore operations include only apps (created by using Power Apps) and flows (created by using Power Automate) in a Dataverse solution.” Manual backups cannot be taken of the default environment, and a system backup cannot be restored over it. An app or flow built outside a solution is not in the restore at all. If business-critical work still lives that way, the first job is moving it into a managed production environment with ALM pipelines, which deploy solutions, as our governance article sets out.

Monitoring and alerts: what the admin center tells you, and when

The Monitor area of the Power Platform admin center is the native place for operational health, and Microsoft’s monitoring overview is clear about its limits. Metrics “are calculated by aggregating daily event logs from runtime activity; they’re not real-time.” Event logs are kept for up to seven days and metrics for up to 28, and “Unused resources don’t appear in Monitor experiences.” Canvas, model-driven and code apps, cloud and desktop flows and Copilot Studio agents are covered; Dataverse and Dynamics 365 apps are listed as not yet available. Health metrics need tenant-level analytics turned on, and recommendations need a managed environment.

Alerts are how a managed service watches the estate between reviews, and Microsoft’s alerts page, as it stands on 11 November 2026, bounds them tightly.

• Custom alerts need Managed Environments. “Managed environments are the only environments that support alerts.”
• There is a ceiling. “You can create up to 10 alert rules with a 1-hour data review period and up to 50 alert rules with a 24-hour data review period for a total of up to 60 alert rules.”
• Hourly is the fastest. Low-latency alerts, in preview, evaluate every hour, and Microsoft says “They aren’t real-time alerts.” Everything else evaluates daily.
• Microsoft’s own alerts are silent. Predefined alerts flag high-use apps, flows and agents with poor health across the whole tenant, but “predefined alerts don’t send any notification”. Someone has to go and look.
• Email reaches five people. The admin who creates a rule and up to four other recipients. A preview trigger on the Power Platform for Admins V2 connector, When an alert fires, can route custom alerts through Power Automate to a Teams channel, Azure DevOps or a ServiceNow workflow, but for now it needs a tenant-admin account and takes only rules with a 24-hour review period, not hourly or predefined alerts.

A limit of sixty rules, only ten of them hourly, forces a choice about which apps and flows are watched closely. That is a risk tiering decision, and an estate without tiers has no basis for making it; our adoption article covers how to tier. It also makes alert routing part of the service design rather than an afterthought, because an email to five addresses is not an on-call rota. Where deeper telemetry is needed, Microsoft positions Application Insights as the step up. Monitor needs no Azure subscription; Application Insights is an Azure service, and it “contains a superset of runtime event logs” and “allows for customer-defined data retention”. In our own estates, alerts that need a response come from telemetry exported to Application Insights and are routed through Azure Monitor into our service desk, and the admin center’s 24-hour rules serve as a daily governance digest.

Platform incidents are a separate feed. Service health and the Message center report Microsoft-side incidents and planned changes, and Microsoft’s policies and communications page says service health keeps “up to 30 days’ worth of history”. A service that does not read both cannot tell its own fault from Microsoft’s, which is the first question in any Power Platform incident.

Releases and change: Microsoft’s cadence has moved

Change management for Power Platform used to mean preparing for two release waves a year, with a release plan to read and an early access switch to test on. All three have changed.

Release plans are archived. Microsoft’s Power Platform release plan address now lands on the 2025 release wave 2 plan, which says “As of October 2026, this content is archived and no longer maintained.” Microsoft points instead to the AI at Work Roadmap, where, per its early access page, features are added “on a rolling basis”.

The early access switch is gone, for now. The same page says “The previous Early Access switch was removed before the April 2026 release. Microsoft plans to reintroduce the switch later in 2026, in advance of the next Semi-annual channel release.” When it returns, Microsoft expects about seven weeks of validation before a semi-annual release and about two before a monthly one.

Model-driven apps default to monthly. Per the release channels page, “When Auto is selected, Power Platform and Dynamics 365 environments use the Monthly channel.” The semi-annual channel turns features on in April and October; the monthly channel turns them on each month “with a one-week advance notification period”. Copilot Studio sits outside these channels, with “separate release and update processes”.

The April and October releases still cannot be postponed. Microsoft’s general availability deployment page says “You can’t postpone the April and October releases.” The October 2026 release reached the first release region on 25 to 28 September and the United Kingdom on 9 to 12 October.

For a managed service, the routine moves from two large events a year to a monthly one. Microsoft’s advice is to “Keep development, test, and production environments on the same release channel so that validation follows the same feature cadence as production”, and because release channel is an environment group rule, it can be set once per group. For model-driven apps that reaches less than it seems: an app’s own channel setting overrides the environment’s, and per Microsoft’s channel change page, “Model-driven apps in Power Platform environments use Monthly when the app release channel is Auto regardless of the environment release channel.” In the estates we manage, the deployment checklist sets business-critical model-driven apps to the Semi-annual channel explicitly, on each app’s properties inside its solution. Not every Microsoft page has caught up: the policies and communications page, dated 30 March 2026, still describes an early access opt-in and points readers to the release plans.

Deprecations run on their own calendar. The important changes page, updated on 2 November 2026, is the other standing read. Its first entry retires Describe it to design it in Power Automate on 30 November 2026. Further down are the end of unmanaged developer environments, covered above, and of Dataverse for Teams environments: none can be created from 15 November 2026, and existing ones not upgraded to Dataverse are suspended on 15 September 2027 and decommissioned on 30 October 2027. Microsoft’s definition explains why these get missed: a deprecated feature “is fully supported until it’s officially removed”, so nothing breaks until the date.

What Microsoft support covers, and what it leaves to you

Power Platform managed services sit between the people using the estate and Microsoft support, so where Microsoft’s support stops defines much of what the service has to do. Microsoft’s support overview for Power Platform and Dynamics 365, dated 3 November 2026, draws the line in several places.

The right-hand column is where a managed service does much of its work. Questions about how a feature behaves, apps that depend on custom code, data repairs and the explanation after an incident in your own estate all fall outside Microsoft’s support, and somebody has to own them.

Four more details shape the service. Only admins can raise a case: “End users can’t open support requests”, and Microsoft’s get support page adds that “to create a support request, you must have an active support plan.” Severity can be lowered, and Microsoft lists issues with customised processes or code among the reasons it may do so. Microsoft will not look at your data without consent: per its support environment page, diagnostic access is “recommended, but it isn’t set by default”, so whoever raises the case decides what Microsoft can see, including whether it may make a full copy of a production environment with its data. And support for services bought through another channel is governed, in Microsoft’s words, “by the agreement terms for that purchase”, with an Enterprise Agreement as its example. Choosing a Microsoft CSP partner covers what to check when a partner sits in that chain.

Where the CoE Starter Kit’s jobs went

The CoE Starter Kit used to supply much of the tooling for running an estate. Microsoft’s kit page now says it “is no longer actively maintained” and “Issues are no longer reviewed or addressed”, and maps its core scenarios to the admin center. Our CoE Starter Kit article covers migrating off it. For a managed service the question is narrower: where each recurring job now runs.

Two Microsoft pages still disagree here. The reactive governance page still recommends the kit’s components for environment and data policy requests and says to report bugs on GitHub; the kit’s own page says issues are no longer reviewed. Follow the kit’s page. We no longer deploy the classic CoE Starter Kit on new tenants: we use the native admin center inventory, Usage insights and Log Analytics instead, and work with the classic kit only where a client already runs it. One side effect for anyone still relying on it: since 20 April 2025, the kit’s queries no longer count as activity in developer environments, so environments kept alive only by those queries now fall to the cleanup schedule above.

Our position: report ownership, not activity

A managed service is judged by what it reports, and the usual numbers are the wrong ones. Monthly active makers and total apps built measure enthusiasm, not whether the estate can be run. We would replace them with two operational health measures. Support tier coverage is the share of high-usage apps assigned to a defined support tier. Verified active ownership is the share of production resources mapped to an active, monitored service account or a named business owner.

Both are harder to produce than they look, which is the point. Inventory’s owner column, Microsoft says, shows the user who created a cloud flow or agent flow and “doesn’t update when the owner changes”, and model-driven apps have no owner at all, so verified ownership cannot be read off a screen. It has to be checked against the pipeline’s deploying identity, the connections each resource uses, and the people still in the organisation. A service that reports these two numbers every month is telling you whether the estate survives the next leaver and the next alert. One that reports usage is telling you it is busy.

Where to start

1. Write the responsibilities down with an owner for each: Microsoft, the service, or a named person inside the organisation, with a backup.
2. Decide which environments are managed. Custom alerts, full Actions recommendations, environment groups and backups beyond seven days depend on it, and all active usage then needs a qualifying licence or pay-as-you-go meter before February 2027.
3. Choose what gets a custom alert within the 60-rule limit, starting from your risk tiers, and route alerts to a team rather than to five mailboxes.
4. Put capacity on a monthly check: Dataverse storage against the 85% notification point, Copilot Credits allocation per environment, and each licence renewal or add-on expiry that ends AI Builder credits.
5. Set release channels per environment group, and on each model-driven app in Power Platform environments, keeping development, test and production on the same one.
6. Move production deployments to delegated deployments, so production objects are owned by a service principal or a nominated user rather than the requesting maker.
7. Agree who raises Microsoft support cases, who holds the support plan, and who decides what diagnostic access Microsoft gets.

Our Managed Microsoft Support, from $1,800/month, covers Power Platform in every tier, alongside Microsoft 365 and Azure, and our Power Platform engagements end in an Operate stage of ongoing enhancement and managed support against an agreed SLA. If your Power Platform estate is live and nobody can say who owns the alerts, the capacity position or the next release, talk to our team.

Frequently asked questions

What do Power Platform managed services include? The continuing work after go-live: environment and environment group requests and clean-up, data policy changes, Managed Environments settings, capacity (Dataverse storage, Copilot Credits and any AI Builder credits still held), licence assignment and requests, deployments through pipelines, monitoring and alerts in the Power Platform admin center, backups, Microsoft’s release and deprecation calendar, and raising Microsoft support cases. Building new apps is project work, even when the same provider does both.

How is a Power Platform managed service different from a governance review? A governance review decides the controls once: environment strategy, data policies, admin roles and routing. A managed service keeps those decisions in force as the estate changes, through change requests, alerts, capacity checks and releases. A project builds apps and flows and ends at handover.

Do you need Managed Environments to run Power Platform as a managed service? For most of the native tooling, yes. Custom alerts work only on managed environments, the Actions page shows full recommendations only for them, environment groups can only contain them, and backup retention beyond seven days is available only for production managed environments. They are premium: all active usage needs a qualifying licence or pay-as-you-go meter, and from February 2027 an unlicensed user cannot open an app in one.

What does Microsoft support cover for Power Platform? Billing, subscription management and technical break-fix issues at every support level, with full technical support where the platform is the cause. It does not cover how-to questions, which Microsoft treats as training, repairing damaged data, or a root cause analysis of your own incident, and problems in custom code that the platform did not cause get only commercially reasonable support. Raising a case needs an admin role and an active support plan.

What replaced the CoE Starter Kit for running a Power Platform estate? Four admin center experiences, Inventory, Usage, Monitor and Actions, with the Power Platform API, the Power Platform for Admins V2 connector and the CLI for automation. Microsoft no longer maintains the kit. Approval workflows for environment and data policy requests have no named native replacement, and Microsoft’s reactive governance page still points to the kit’s components for them.

Anuj Kumar Mishra

Operations head with 20 years of experience delivering business intelligence, ERP and AI programmes across healthcare, finance and manufacturing. Focus areas include Power Platform adoption and governance, delivery models, and managed services.