Power Platform landing zone: what to set up before makers arrive

If you are looking for Microsoft’s Power Platform landing zone, the honest answer is that its current documentation does not define one. Microsoft used the term in 2022, for a reference architecture that treated landing zones as environments, and archived the GitHub repository holding it in March 2025. The ground it covered has not gone away. Microsoft now documents most of it as a tenant environment strategy, spread across more than twenty admin and guidance pages that do not always agree.

This article is about Power Platform, not Azure. It maps the old term to what Microsoft documents today, then sets out the foundation we build before the first maker arrives, in the order we set it: admin roles, environment creation, tenant isolation, data policies (still called data loss prevention, or DLP, policies on some Microsoft pages), environment groups and ALM, the default environment and routing, and a support route, with the licences and capacity all of that commits you to. Several Microsoft changes land between 15 November 2026 and February 2027, and each of them changes the design.

Is there a Power Platform landing zone?

There was, and the record is short.

In February 2022, Ken Auguillard and Kristian Nese published Reference Architecture and Landing Zones for Power Platform on Microsoft’s Power Platform blog. Their definition fits in a line: “The outcome of the Reference Architecture is the ‘Landing Zones’ (Environments)”. They presented it as a first iteration, and the work’s earlier name, North Star, survives in the post’s URL.

The reference implementation, Power Platform Landing Zones, lived in Microsoft’s industry repository on GitHub. Its README is the closest Microsoft has come to stating the idea behind this article: a landing zone existed “to ensure that when an app is being created, the required ‘plumbing’ is already in place”. It organised the design into eight critical design areas (licensing and Azure AD tenants; identity and access management; security, governance and compliance; environments; management and monitoring; business continuity and disaster recovery; connectivity and interoperability; platform automation and DevOps), and it shipped a “Landing Zones vending machine” to create landing zones for citizen and professional developers at scale.

That folder was last changed in September 2023. The repository now reads “This repository was archived by the owner on Mar 15, 2025. It is now read-only.” The aka.ms link in the 2022 post still redirected there when we checked on 19 October 2026. Read the README as history: parts of it, including its licensing notes and CoE Starter Kit recommendations, describe the platform as it stood when it was written.

What Microsoft documents now

We checked 41 current Power Platform and Copilot Studio admin and guidance pages on Microsoft Learn, covering environments, routing, groups, managed environments, data policies, tenant isolation, admin roles, pipelines and capacity. None of them uses the term landing zone.

In the Cloud Adoption Framework, where Microsoft defines the term, a landing zone is an Azure idea. The framework calls it “a proven and flexible architecture for governing, securing, and scaling a multi-subscription Azure environment”, and its own diagram draws Copilot Studio below it, not inside it: “Beneath the Azure landing zone, Microsoft Copilot Studio, Microsoft Fabric, and Microsoft 365 are shown as integrated business, data, and AI solutions.” The framework article with Power Platform in its title extends an Azure SAP workload landing zone so a Power Platform environment can connect to it. It does not define a Power Platform one.

No Microsoft page says the concept was retired or replaced, either. What is documented is narrower: the repository is archived. The current name for the same ground is in Microsoft’s environment strategy guidance: “A tenant environment strategy lays the foundation to help accelerate usage in a manageable and secure fashion.” Its only link to the Cloud Adoption Framework is as optional reading: “You might find inspiration in the cloud operating models that are part of the Cloud Adoption Framework for Azure.”

Two other names look like the answer and are not. The adoption guidance’s Get ready phase shares a name with the Cloud Adoption Framework’s Ready phase, but it covers training, a community hub, internal events and use cases. The environment strategy sits under governance, where Microsoft’s admin best practices list “Establish an environment strategy.” And Power Platform Well-Architected is about “modern application workloads”, not the tenant they run in.

If you came here for the Azure kind, with management groups and subscriptions, our Azure landing zone accelerator article is the one you want.

From the 2022 design areas to today’s documentation

The mapping below is ours, not Microsoft’s. Microsoft has not published one.

The 2022 design also covered business continuity and connectivity, which this article does not.

Why “before makers arrive” is the whole point

Microsoft’s guidance is direct about timing. Its environment strategy page calls the stage before any environments exist greenfield and says “This is the best time to implement an enterprise-scale environment strategy that’s aligned with product features and best practices.” It warns in both directions: “Establishing a solid foundation now is essential to avoid having to wrangle an out-of-control situation that can occur later”, but “avoid the temptation to over-engineer your environment strategy by adding complexity that isn’t required.”

The first reason is mechanical. Four of the main controls are free to set on an empty tenant and harder to set afterwards, and Microsoft’s own pages describe what happens if you wait.

None of those is a reason to delay a rollout. All of them are reasons to set the controls first.

The second reason is the failure we see most often. Microsoft’s adoption maturity model rates disciplines such as community, support and governance separately, on levels from 100 (Initial) to 500 (Efficient). The most common structural failure across enterprise tenants is a maker community at maturity level 200 or 300 sitting on governance and support still at 100: maker activity evangelised before any intake process, ALM or tiered support exists. In the troubled estates we are asked to review, the gap comes from launching the platform on licences first and promising governance for later, and once makers have momentum, retrofitting guardrails feels to them like confiscation. A foundation is what stops the community getting that far ahead.

The foundation, in the order we set it

We configure a new tenant from the outer boundary inward, so that no maker can create an unmonitored environment, move data out of the tenant or trigger a licensing shock while the foundation is still being built. Admin roles come first, then the tenant-wide controls, then the environments inside them, and makers are invited last. The order is ours, not Microsoft’s, but it respects the dependency in Microsoft’s pages that matters most, which step 4 sets out.

1. Name the platform owner, and put admin roles behind PIM

The first decision is a name, not a setting: who owns the platform once it is built, for reasons our position below sets out. The second is who can change it.

Microsoft’s guidance is short: “Limit the more powerful Power Platform admin role to just a few users”, and “Use Privileged Identity Management (PIM), a feature of Microsoft Entra ID, to manage, control, and monitor the use of these high-privilege roles.” We apply it literally: two to four named people eligible for the Power Platform Administrator role through PIM, none holding it standing, and each activation needing multifactor authentication and a business justification and lasting four to eight hours. Only two emergency break-glass accounts have standing access.

Inside environments, the equivalent is a break-glass System Administrator. Microsoft recommends assigning “the system administrator security role to a few trusted users without assigning those users the Power Platform administrator role”, to avoid an administrative lockout. We give that role to a dedicated break-glass identity in the default environment and in each core production environment.

It matters more than it used to, because tenant roles no longer bring the System Administrator role inside each environment with them. Per Microsoft’s admin roles page, when the Dynamics 365, Power Platform or Global administrator role is assigned in Microsoft Entra ID, “the user is no longer automatically assigned to the system administrator role in environments.” Who holds System Administrator in each environment is a decision to record, not a side effect of an Entra role.

Do not build the admin model on scoped roles yet. Power Platform role-based access control, which scopes roles to the tenant, an environment group or an environment, is in preview, and scoped permissions in the admin centre experience “are on the roadmap but aren’t yet finished.”

2. Restrict who can create environments and trials

Microsoft’s environment creation page says that, under the new provisioning model, “users with the correct licenses can create an environment as long as 1 GB of capacity is available.” Microsoft recommends you “Restrict the creation of net-new production environments to admins”, and in its worked example “Only admins are able to create trial, sandbox, and production environments.” Manual creation of developer environments has its own setting on the same page, Developer environment assignments, and Microsoft’s routing page says routing (step 6) is unaffected by it.

We limit all four types, production, sandbox, trial and developer, to admins in the tenant settings, and where the organisation’s policy permits, we restrict self-service trial sign-ups as well. Skip this and makers create shadow environments before any policy exists to cover them.

3. Turn on tenant isolation in both directions, on day one

Tenant isolation is off by default. Microsoft’s tenant isolation page says that with it off, cross-tenant connections are “established seamlessly, if the user from tenant A establishing the connection to tenant B presents appropriate Microsoft Entra credentials.” Microsoft’s tenant-level recommendations include applying cross-tenant isolation to reduce the risk of data exfiltration between tenants.

We turn it on for inbound and outbound connections on the first day, while the estate is empty, because switching it on after makers arrive breaks the cross-tenant connections nobody documented. Exceptions go on what Microsoft calls “an explicit allow list of tenants that they want to allow inbound, outbound, or both”, and we add only tenants approved in advance. Two kinds come up: separate tenants within the same corporate group (subsidiaries, sister brands, regional holding companies) that share data across internal legal boundaries, and external delivery or partner tenants that connect across the boundary for ALM or shared storage.

Know its scope before relying on it. It “only works for connectors using Microsoft Entra ID-based authentication such as Office 365 Outlook or SharePoint”, it “affects Power Platform canvas apps and Power Automate flows”, and Microsoft lists a known issue with the Azure DevOps connector, for which the policy is not enforced. The page does not mention Copilot Studio agents, so do not assume it covers them.

4. Set the tenant-wide baseline data policy, then advanced connector policies on the groups

Microsoft documents two models of data policy, which are easy to confuse. We run both, in mixed mode.

The outer net is a classic tenant-level policy. Classic data policies classify connectors as Business, Non-business or Blocked, as our governance article explains, and leave a set of connectors that cannot be blocked. “Tenant-level policies can be defined to include or exclude specific environments”, and for the tenant-wide case Microsoft’s walkthrough says: “We recommend keeping the default setting as Non-business to map any new connectors added to Power Platform by default.” Our baseline blocks high-risk connectors, puts SharePoint, OneDrive, SQL Server, Dataverse and Outlook in Business, and leaves everything else Non-business or Blocked. It goes on before any environment opens to makers, so that the default environment and any stray environment are covered without anyone having to remember them. The environment routing page is why it cannot wait: “No specific data policies are assigned to the developer environment. The developer environment inherits existing, tenant-level data policies.”

Inside the groups, advanced connector policies on default deny. Advanced connector policies (ACP) replace the classic model “with a strict allowlist that blocks all connectors by default”, set per environment or deployed through environment groups, and we allow only connectors we have vetted. On managed environments, “you can block any connector or any action, including those that are nonblockable in classic data policies.” Three limits matter for a foundation:

• “Custom connectors and HTTP connectors aren’t yet supported”, so those still need a classic policy.
• ACP runs in mixed mode alongside classic policies by default, and “the most restrictive settings from both are enforced.”
• General availability arrives one workload at a time. Microsoft says each maker portal’s release of design-time enforcement (Power Automate first, then Copilot Studio, then Power Apps) “marks the general availability of ACP for that workload”, and until then ACP is enforced at runtime only.

A routed environment inherits the tenant-level policy and its group’s published rules, which can include an advanced connector policy; with neither in place, it starts life with no connector policy at all.

5. Create the environment groups, the pipeline host and the core environments

Groups come before the environments they will hold, so that their rules are in place before the first environment joins. Environment groups are where a foundation is enforced at scale, with hard constraints. They “can only contain managed environments”; “Each environment can belong to only one group, and groups can’t overlap or be nested”; and “Per-environment exceptions aren’t currently supported.” A published rule is locked in every member environment, “ensuring that local system administrators can’t modify or override these centrally defined rules.” An environment that needs different treatment therefore needs a different group, so decide what each group is for before creating it. For example, we separate maker development, where routing places makers’ developer environments, from departmental test and production, and both from enterprise-critical workloads. Microsoft’s worked example, for the fictional Contoso, is a useful reference point: “Four environment groups are created: Development, Shared Development, UAT (user acceptance testing), and Production.” Its warning about over-engineering applies to anything added beyond that.

The rules page lists 28 rules, including Advanced connector policy, Default deployment pipeline (preview), Sharing controls for canvas apps, Sharing controls for solution-aware cloud flows, Solution checker enforcement, Unmanaged customizations, Release channel and Usage insights. Check which of yours are previews: “The rules that have “(preview)” in their name are in public preview, while rules without it are considered generally available.”

The core environments. Alongside the groups we create the initial Development, Test and Production environments. Microsoft states the principle: “a key tenet of a good environment strategy is to isolate where an asset is built from where it’s deployed and used.” Two decisions belong at creation. Microsoft recommends provisioning Dataverse “in any environment where makers create assets that will be shared with other users”, and Dynamics 365 has to be decided then too, because “you must enable Dynamics 365 when you create the environment or you won’t be able to install Dynamics 365 apps later.”

The pipeline host. Pipelines connect them. Microsoft’s pipelines FAQ makes two exceptions: “Developer environments aren’t required to be managed environments”, and “The pipelines host should be a production environment, but the pipelines host doesn’t have to be a managed environment.” Then: “All other environments used in pipelines must be enabled as managed environments.” Microsoft is enforcing the rule for targets now: “Starting in October 2026, the admin deployment page notifies admins when pipelines deploy to unmanaged target environments. Admins have 30 days to approve enabling managed environments before future deployments to the target are blocked.” One further 30-day extension is available per environment.

For enterprise deployments we use a custom host rather than Microsoft’s platform host, for three reasons. Pipeline administration can be delegated without tenant-wide admin rights: installing the pipelines application adds two security roles, Deployment Pipeline User, which “Has privileges to run pipelines that have been shared with them”, and Deployment Pipeline Administrator, which “Has full control over all pipeline configuration, without needing system administrator security role membership.” Runs can carry approvals and other gated steps before deployment, and trigger custom logic when it completes; Microsoft’s extend pipelines page says “you can add approvals, deploy via service principals, and integrate with internal systems of record, Azure DevOps, GitHub, and much more.” And the deployment history sits in a Dataverse environment we control and back up, because the host “acts as the storage and management plane for all pipeline configuration, security, and run history.”

Microsoft’s ALM guidance puts the reason for all of this plainly: “Don’t treat low-code workloads as low complexity.”

6. Rename the default environment, give it its own data policy, and route licensed makers

The default environment, in Microsoft’s words, “isn’t intended for long-term or permanent work beyond the Microsoft 365 personal, productivity scenarios.” It is still where everyone starts. Per the environments overview, “Whenever a new user signs up for Power Apps, they’re automatically added to the Maker role of the default environment”, and it “doesn’t provide any backup guarantees and shouldn’t be used for production workloads.” Access to it cannot be blocked, so Microsoft’s answer is to make it safe early: “Securing the default environment is a priority.” Microsoft calls that, with tenant-level security, “part of the first step in your environment strategy”. In our order the tenant-level half is steps 2 to 4; the environment’s own guardrails come here, still before any maker is invited.

• Rename it. It is created as “TenantName (default)”. Microsoft suggests “something more descriptive, like Personal Productivity Environment”.
• Give it its own data policy. If it is managed, Microsoft now recommends “Blocked: All connectors”, which needs ACP. If it is unmanaged, which is our default (see below), the fallback is to “block new connectors, limit makers to prebuilt connectors, and limit custom connectors”. It is stricter than the step 4 baseline by design, because this environment is meant for personal productivity only.
• Check Share with Everyone is off. Microsoft’s secure default environment guidance says the feature “is disabled by default in Power Platform. We recommend you keep this setting disabled”. Check it is still off; the environment strategy page still says “Consider turning off the Share with Everyone feature”.
• Sharing limits need it managed. Microsoft’s Limit sharing page says “In managed environments, admins can limit how broadly users can share canvas apps, flows, and agents.” Sharing limits therefore apply to the default environment only if you decide to manage it.

Whether to manage it is where Microsoft’s own pages pull apart. Its secure default guidance recommends “making use of managed environment features in the default environment”. Its licensing page says “Every user who runs an app in a managed environment is in scope, including users who run standard apps”, and “Starting February 2027, an appropriate license is strictly required for a user to open an app in a managed environment.” We found no Microsoft page documenting an exception for the default environment.

Our rule is to keep the default environment unmanaged, for personal Microsoft 365 productivity under a strict data policy and a manual audit, and to use managed environments for the development, test and production environments in the groups, where users are licensed through Entra security groups. We manage the default environment only when the client already holds or has budgeted standalone licence coverage across the whole enterprise, or is moving out of the default environment altogether.

If your default environment is already full of makers’ work, the sequence is different, and it is the subject of our Power Platform governance article.

Routing. Environment routing “is a premium governance feature” that sends new or existing makers to their own developer environments “when they visit Copilot Studio, Power Apps, Power Automate, or Power Automate for desktop.” It is off by default, and “If no rule matches, or if environment routing isn’t turned on, the maker is routed to the default environment.” Makers can also leave once routed, because “makers can always switch to other environments”, which is why the guardrails above matter as much as routing does.

• Rules. Routing can apply to everyone or to specific security groups, and multi-rule routing sends makers “to multiple environment groups based on rule logic”, in priority order. Separately, “You can’t assign security groups to developer environments.”
• What each environment gets. No data policy of its own, as step 4 explains, and sharing “Set to exclude sharing with security groups, and preconfigured to share with five individuals.”
• Licensing. “A premium license isn’t required for the creation or preview of an app or flow in a managed developer environment. However, a user or maker needs a premium license to run an app or flow in a managed developer environment.” The Developer Plan does not change that: makers “need a premium license in addition to the developer plan to run their assets”.
• Capacity. “No, the developer environments don’t affect your tenant Dataverse quota.”

Microsoft recommends pairing routing with environment groups: “You can use environment routing by itself, but the recommended way is to use it with environment groups.”

Who gets routed. We route a dedicated Entra security group of licensed makers, not everyone. From 15 November, the Developer Plan page says, “each user can create only one managed developer environment”, and running assets in it needs a premium licence. Route everyone, and any curious user who opens a maker portal gets an environment they can build in but, without a premium licence, cannot run anything from, while the admin centre fills with empty environments. A light onboarding check, a licence assigned and a one-page set of maker rules read, is what adds a maker to the routed group.

The dates. Microsoft’s important changes page says: “You can’t create new unmanaged developer environments starting November 15, 2026. Existing unmanaged developer environments are suspended starting December 15, 2026 and deleted starting January 15, 2027.” Managed ones, including “the personal developer environments that environment routing creates”, are not affected. Microsoft’s reason is this article’s subject: unmanaged developer environments “sit outside many of the governance controls that admins rely on”. Inactive managed personal developer environments are disabled after 60 days without activity, against 30 for unmanaged ones, and deleted if nobody re-enables them.

If makers in your tenant create their own developer environments today, routing should be on before 15 November. Any unmanaged developer environment worth keeping needs managed environments enabled on it, or its solutions exported to another environment, before 15 December; Microsoft’s managed environments overview and Developer Plan page give those two routes.

The important changes page closes one more option: “You can’t create new Dataverse for Teams environments starting November 15, 2026”, and existing ones that are not upgraded are suspended on 15 September 2027 and decommissioned on 30 October 2027. Leave them out of a new design.

7. Open the support route and the inventory before inviting a single maker

Before the first maker is invited, we put in the internal request form and support channel for the three requests the controls above will generate: connector exceptions, environment requests and pipeline promotions.

Admins also need to see what makers build from the first day. We no longer deploy the classic CoE Starter Kit on new tenants, for the reasons in our CoE Starter Kit article. We use the admin centre’s native inventory, Usage insights for managed environments and an export to Log Analytics instead, and work with the classic kit only where a client already runs it and needs help maintaining it or leaving it.

What we refuse to skip

We refuse to skip four of the seven steps: 2, 3, 4 and 7. Skip any of the first three and shadow IT starts on day one, in environments nobody approved, connections to tenants nobody listed and connectors nobody vetted. Skip the support route and makers bypass the platform the first time a control blocks them.

What the foundation commits you to: licences and capacity

Managed environments “are a suite of premium capabilities”. A foundation built on Microsoft’s current guidance pulls them in at four points, whether or not anyone set out to turn them on: routing creates managed developer environments, environment groups only hold managed environments, every pipeline environment except the host ends up managed once no unmanaged developer environment is left running after 15 December, and ACP blocks connectors that classic policies cannot only on managed environments.

So premium licensing is a design input, not a procurement question for later. The licensing page is explicit: “When you activate managed environments in an environment, all active usage requires one of these standalone licenses or pay-as-you-go meters”, with the February 2027 hard block in step 6 behind it. Microsoft also recommends “configuring license auto-claim if your environment strategy includes managed environments.” Which licences qualify, and how the notifications escalate, is in our managed environments licensing article.

Capacity is the other commitment. “Capacity is shared across the tenant so it needs to be allocated to those who need it,” says the environment strategy page, and Microsoft’s capacity page lists “Create new environment (requires minimum 1-GB capacity available)” among the operations that stop when it runs out. Routed developer environments do not count against the tenant Dataverse quota. The environments admins create for shared work do.

As a Microsoft CSP, Veratas advises on Power Platform per-app, per-user and pay-as-you-go model selection, which is where this section ends up.

Where Microsoft’s own pages disagree

Microsoft’s environment strategy page (updated 12 October 2026) is the best single read on this subject, and in places it is behind the feature pages. Where they disagree, we follow the feature page.

One more is covered elsewhere. The environment strategy page still says a gap “can be filled using the Power Platform Center of Excellence Starter Kit”, while the kit’s own page says it “is no longer actively maintained”. What that means is in our CoE Starter Kit article.

Our position: govern where makers can build, not what they can build

Our position has three elements: support before evangelism, containment rather than lockdown, and a named owner from the first day.

The order first. The community dimension must never be allowed to run ahead of the support dimension, because makers who hit throttling, a data policy block or a deployment problem with no support path either abandon the platform or flood a service desk that was never trained for it. Every control in this article creates a moment where a maker is stopped, and the foundation is not finished until someone is there to answer them.

Then the purpose. Locking down maker rights outright does not reduce risk, it exports it: citizen developers relocate into unmonitored external SaaS with no DLP, no audit trail and no tenant boundary. Our governance article makes that case for estates that already have makers. On a new tenant, routing makers into contained environments is the alternative to locking them out.

And a named owner from the first day. The most common shape we see across engagements is not a failed project but a successful one: the build lands, the team demobilises, and the central platform responsibilities were never assigned because they were in nobody’s scope. Power Platform foundations follow the same pattern: project teams build the apps and leave assuming IT operations owns the foundation, while IT operations assumes the delivery team does. Tenant settings, the data policy, group rules and the pipeline host are central platform responsibilities. Somebody has to own them after the project that set them up has gone.

Where to start

1. Name the owner of the foundation before configuring anything.
2. Put admin roles behind PIM, with break-glass access.
3. Restrict environment and trial creation to admins: production, sandbox, trial and developer.
4. Turn on tenant isolation in both directions, with only tenants approved in advance on the allow list.
5. Write the tenant-wide baseline data policy before routing goes on, then advanced connector policies on the environment groups, with custom and HTTP connectors on the classic policy either way.
6. Model premium licences and capacity, including the February 2027 change, before the first managed environment exists.
7. Create the environment groups, the pipeline host and the core environments, noting which group rules are still in preview.
8. Rename the default environment, give it its own data policy, and route a security group of licensed makers, before 15 November if makers create their own developer environments today.
9. Open the request and support route, then invite makers, and tell them what each environment is for. Microsoft’s warning is blunt: “If you simply activate your strategy without any communication, users see the changes as restrictions and look for ways to work around them.”

In a Veratas Power Platform engagement, the Govern stage covers environment strategy across development, test and production, the Dataverse data model, data loss prevention policies that separate business and non-business connectors, and ALM with solution-based pipelines. If makers are about to arrive in your tenant, talk to our team before they do.

Frequently asked questions

Is there an official Power Platform landing zone? Not in Microsoft’s current documentation. Microsoft’s Power Platform blog introduced landing zones for Power Platform in February 2022, defined as environments, and the reference implementation sat in Microsoft’s industry repository on GitHub, which was archived on 15 March 2025. Microsoft now documents the same ground as a tenant environment strategy.

Is a Power Platform landing zone the same as an Azure landing zone? No. In Microsoft’s Cloud Adoption Framework, a landing zone is an architecture for a multi-subscription Azure environment, and its own diagram places Copilot Studio beneath it as an integrated solution rather than inside it. A Power Platform foundation is built from environments, data policies and admin settings in the Power Platform admin centre.

What should be in place before makers start building? In the order we set it: a named owner and admin roles behind Privileged Identity Management; admin-only environment and trial creation; tenant isolation in both directions; a tenant-wide baseline data policy, with advanced connector policies on environment groups; the groups, a pipeline host and the core environments; a renamed default environment with its own data policy, and routing for licensed makers; and a support route. Premium licences and capacity are modelled before the first managed environment exists. Environment creation limits, tenant isolation, data policy changes and sharing limits all bite harder once apps exist.

What changes for developer environments in November and December 2026? From 15 November 2026 nobody can create new unmanaged developer environments, and each user can create only one managed developer environment. Existing unmanaged developer environments are suspended from 15 December 2026 and deleted from 15 January 2027. Managed developer environments, including the ones environment routing creates, are not affected.

Do we need managed environments for a Power Platform landing zone? In practice, yes. Environment routing creates managed developer environments, environment groups only hold managed environments, pipeline targets must be managed, and advanced connector policies can block every connector only on managed environments. The default environment is the one we keep unmanaged, unless enterprise-wide standalone licence coverage is held or budgeted, or the default environment is being vacated. All active use of a managed environment needs a qualifying licence or pay-as-you-go meter, and from February 2027 an appropriate licence is strictly required to open an app there.

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.