Message center post MC1469329 announces a preview of natural-language app building in Copilot Cowork, with a matching experience coming to Copilot Studio. Rollout for Cowork ran from September 8 to September 14. It carries both ADMIN IMPACT and USER IMPACT tags and a high relevance rating, which is appropriate.
Most of the post reads as reassurance. Apps use Microsoft Entra authentication. Apps follow your existing connector, environment, data, security, compliance, and sharing policies. Makers are routed to an isolated personal developer environment with secure defaults. Published apps appear in the Microsoft 365 admin center.
Then there is this sentence, the second to last bullet in the impact section: for organizations that have not enabled environment routing, routing will be automatically applied to apps created through these experiences.
That is a premium governance feature being switched on in tenants that did not ask for it, described in twenty-four words in the middle of a bulleted list. The supporting Microsoft Learn documentation is considerably more direct, and it contains a detail that inverts who has work to do.
What actually shipped
The mechanics first, because they are genuinely interesting.
In Copilot Cowork, a maker invokes an app skill in chat and describes the business outcome, the users, the data, and the actions. Copilot generates a working app scaffold, and the maker iterates in natural language, previews the result alongside the conversation, and can inspect the underlying code. Apps can reach organizational data through connectors, including Work IQ for organizational context. An app built in Cowork can be opened and edited further in Copilot Studio.
Availability during preview is narrow. Cowork app building requires enrollment in the Frontier Program, a Microsoft 365 Copilot license, and access to Cowork. The Copilot Studio experience is the one to watch, because when it arrives Microsoft states it will be enabled by default for eligible makers, with admins able to turn it on or off and scope it to security groups during preview.
Published apps surface in the Microsoft 365 admin center under Apps, and users discover shared apps at a dedicated managed apps address. Both building and running are metered under usage-based billing through Copilot Credits.
The routing change, stated plainly
Microsoft published a dedicated Learn article, Environment routing for apps, on the same day the rollout began. It opens with a sentence the message center post does not match in directness: apps you create in Copilot Cowork automatically enable environment routing, a premium governance feature, in all tenants, and you cannot change this setting.
Three things are stacked in there. Environment routing is now on for apps everywhere. It is a premium governance feature, previously something an admin chose to configure. And the setting is not yours to change.
On the merits, this is defensible. Routing makers into isolated personal developer environments rather than letting generated apps land in the default environment is exactly what a governance team would want. Microsoft is applying a control most organizations should have had already, scoped narrowly to apps, and explicitly not affecting other resources created in Power Platform or Copilot Studio.
The interesting part is what it does to tenants that already did the work.
Doing nothing worked. Doing the work did not.
If your tenant had no routing configuration, Microsoft handles everything. You get a single routing rule sending Everyone to their personal developer environment, and a new Default Environment Group is created automatically to hold them. Your makers can build apps. There is nothing for you to do on day one.
If your tenant already had routing rules, no new rule is added. The Learn documentation states the consequence without softening it: some makers in these tenants might not be able to use apps, and an admin should create a new routing rule for Everyone.
Read those two outcomes next to each other. The organization that never configured environment routing gets a complete, working setup delivered automatically. The organization that invested in a routing strategy, built rules around security groups, and thought carefully about which makers go where, gets a partially applied feature and a documentation note telling it to go fix the gap.
The engineering logic is sound. Microsoft cannot safely inject a tenant-wide rule into a configuration someone deliberately designed, and overwriting a considered routing hierarchy would be worse than leaving it alone. But the practical effect is that governance maturity converts into a to-do item, and the signal it sends to admins is not a good one.
The constraints you have not hit yet
Further down the same article are four rules that now govern routing configuration generally. None of them will announce themselves. You will meet them the next time you try to change a routing rule.
- The routing rule targeting Everyone cannot be deleted by an admin.
- Only one routing rule may target Everyone. Tenants with more than one must clean up the configuration before making any changes to routing rules.
- The Everyone rule must sit last in priority order. Tenants with an Everyone rule above a security group rule must adjust the priority before making further changes.
- New routing rules cannot be created without selecting an environment group.
Note the phrasing on the middle two. Before making any changes. Before making further changes. These are not warnings about the rules you are editing. They are blocks on editing anything until the existing configuration conforms.
If your routing configuration predates these constraints and violates one of them, you are currently locked out of routing changes and probably do not know it. The organizations most likely to be affected are, again, the ones with the most elaborate routing setups. Checking this now costs ten minutes. Discovering it during an incident, when you need to redirect a group of makers quickly, costs considerably more.
Where this starts costing money
The personal developer environment is not a neutral container, and the licensing behavior attached to it has a branch in it that matters.
These environments are managed environments by default, and they ship without Dataverse. A maker who stays inside app building does not require a premium Power Apps or Power Automate license, and auto-claim does not apply.
A maker who creates Power Apps or Power Automate resources in that environment does require the appropriate premium licenses, because managed environment requirements apply. The documentation is careful to say this holds whether the maker explicitly selected the environment or was routed there by an admin’s configuration. Auto-claim applies in this scenario. Dataverse is also added automatically the moment a maker visits a Power Apps or Power Automate maker surface and lands in that environment.
Follow that chain through. Natural-language app building lowers the barrier to becoming a maker to roughly zero. Every new maker gets a personal developer environment. That environment is a managed environment. The moment curiosity carries someone from the app canvas into Power Apps, a premium license requirement attaches and auto-claim can satisfy it without anyone approving a purchase. Meanwhile Dataverse appears in an environment nobody planned for.
None of that is hidden, and none of it is unreasonable on its own terms. But it is a cost path that runs from a chat prompt to a licensing event with no human decision in the middle, and it arrives in the same quarter that Power Apps Premium list pricing goes up on January 1. If you have not reviewed your auto-claim posture recently, this is the reason to do it.
Separately, Copilot Credits meter both app building and app running under usage-based billing. That is a different meter from Power Platform licensing, and it applies on both branches of the diagram above. Microsoft’s own recommended actions include reviewing Copilot Credits requirements and configuring usage-based billing, which is worth treating as a real task rather than a footnote.
The admin center question
Every administrative action Microsoft recommends in this post happens in the Microsoft 365 admin center. Frontier Program onboarding and enabling app creators under Apps and Overview. Reviewing default configuration under Apps and Settings. Published app inventory under Apps and All apps.
Meanwhile the environment routing behavior, the environment groups, the managed environment settings, and the Dataverse provisioning all live in the Power Platform admin center.
This is the same split that showed up with agent model selection and with agent authentication, and it is becoming the defining shape of Power Platform governance rather than a temporary artifact. The capability is presented and toggled in one admin center. Its consequences are configured and observed in another. In most organizations those two consoles have different owners, different review cadences, and different people on call.
The practical answer is not to argue about which console should own it. It is to make sure someone is reading both, and that your governance documentation names the specific console for each action rather than saying the admin center and assuming the reader knows which one.
What to do
- Open environment routing in the Power Platform admin center and look at what is there now. Whether you enabled routing or not, something changed on September 8.
- If you had existing routing rules, check whether a rule targeting Everyone exists. If not, create one, because without it some of your makers cannot use app building.
- Audit your routing configuration against the four new constraints. More than one Everyone rule, or an Everyone rule not last in priority, means you are blocked from routing changes until you fix it.
- Look for a new Default Environment Group. If your tenant had no prior configuration, one was created for you, and it now holds every maker’s personal developer environment.
- Review auto-claim policy configuration before the Copilot Studio experience arrives enabled by default. This is the mechanism that converts maker curiosity into licensed users.
- Decide your position on the Copilot Studio experience now. It will be on by default for eligible makers, and the window to scope it to security groups is during preview.
- Review Copilot Credits and usage-based billing configuration, since both building and running consume them.
- Work out who in your organization watches the Apps area of the Microsoft 365 admin center, and whether that is the same person who watches the Power Platform admin center.
- Plan for personal developer environment sprawl. Every maker gets one, they are managed environments, and Dataverse can appear in them without a provisioning request.
The read
Two things are true about this release at once, and holding both is the right posture.
Microsoft shipped a genuinely governed version of a feature that could easily have shipped ungoverned. Isolation by default, secure defaults, Entra authentication, existing policy enforcement, central inventory. Compared with how low-code capability has historically arrived in tenants, this is a substantial improvement, and the people who built it clearly thought about the admin.
And a premium governance feature was turned on in every tenant, with a configuration that completes itself only where no one had done the work, a set of new constraints that will surface as blocked operations rather than notifications, and a licensing path that runs from a chat prompt to a premium seat without a human decision.
The message center post gives the first version. The Learn article gives the second. Both are Microsoft’s own words, published on the same day. That gap is the argument for reading the documentation rather than the notification, and it is not going to get smaller as capability ships faster.
Sources
- Microsoft 365 message center post MC1469329, published September 8, 2026
- Environment routing for apps, Microsoft Learn
- Default environment routing, Microsoft Learn
- Build business apps with Copilot Cowork and Copilot Studio, Microsoft Copilot Blog