Someone in HR opens a SharePoint list and customizes the form to make it easier to fill out. Nothing about that is wrong. But Power Apps just built a canvas app to run that form, and it landed in the one place in your tenant with almost no governance around it – the default environment. Multiply that by every maker who builds a quick app and every flow someone wires to a SharePoint library, and the default environment becomes the largest ungoverned surface in your Microsoft 365 estate.
Microsoft shipped a tool this year to help you clean it out. It is worth using, and it is worth understanding why the cleanup alone will not hold.
What is the Power Platform default environment?
The default environment is the shared Power Platform space every Microsoft 365 tenant gets automatically, and every user is a maker in it by default. Anyone can build apps and flows there without requesting access or approval. It has no Managed Environment controls, only tenant-wide DLP rather than granular policy, no connector boundaries per team, and no real lifecycle management.
It also fills up without anyone deciding it should. When a user customizes a SharePoint list form with Power Apps, the resulting canvas app is created in the default environment. Flows built from SharePoint use the default environment too. So even teams that never set out to build on Power Platform are populating this space every time they improve a form or automate a list. The path of least resistance runs straight through the one environment nobody is governing.
Why the default environment becomes a governance problem
It becomes a problem because everyone can build there, everything they build collects in one place, and nobody owns the result. Over months, the default environment accumulates experimental apps, customized SharePoint forms, one-off flows, and abandoned test projects, which makes ownership unclear and DLP hard to enforce.
The risk is not abstract. An app sitting in the default environment can connect to SharePoint data, pull from Exchange, or reach an external connector, and the only thing between it and a data-loss incident is a tenant-wide DLP policy that cannot tell a sanctioned finance app from a maker’s weekend experiment. Ownership is the other half. When the person who built an app changes roles or leaves, the app keeps running, still connected to live data, with no one to answer for it. This is the same sprawl pattern that runs through Power Platform governance generally, concentrated in the one environment least equipped to handle it. And because SharePoint lists are usually the data layer underneath these apps, the exposure runs in both directions.
Microsoft’s new tool for moving apps out of the default environment
Microsoft added a Power Platform Advisor recommendation, generally available since April 30, 2026, that finds canvas apps and custom SharePoint forms sitting in the default environment and helps administrators move them into Managed Environments. From the recommendations page in the Power Platform admin center, you can migrate apps manually, reviewing each one individually, or in bulk through an automated Power Automate flow for larger cleanups.
When you move an app, you decide what happens to the original – leave it in place, quarantine it so users cannot run it while you review, or delete it outright. There is one meaningful limit. Only canvas apps and SharePoint forms that do not use shared connectors or resources are eligible to move through this path. Managed Environments are the destination, and they are where the real controls live: which connectors are available, who can share apps, and what data is allowed to move between environments.
Why the tool is a cleanup, not a cure
Moving apps out of the default environment clears the backlog, and it does nothing to stop the next app from landing there tomorrow. The environment stays open, every user stays a maker, and the next customized SharePoint form drops a fresh canvas app right back into it. Run the cleanup and change nothing else, and you will be running it again in six months.
Two details make that sharper. The eligibility rule excludes any app using shared connectors, which tends to describe the more complex, more connected, higher-risk apps – exactly the ones you most want out of an ungoverned space. So the automated cleanup handles the easy cases and leaves the hard ones sitting where they were. And moving an app relocates the file without resolving its ownership, its access rights, or its data connections, so a poorly governed app in a Managed Environment is still poorly governed. The tool is a broom. What the default environment needs is a gate.
What actually closes the gap
The fix is to make the default environment a place apps pass through rather than pile up in, which is a set of decisions rather than a single setting. The cleanup tool is one step inside that, not a substitute for it. Four moves matter more than the migration itself:
- Stand up Managed Environments with DLP and connector policies as the real homes for business apps, so there is somewhere governed for apps to live.
- Redirect where custom SharePoint form apps are created, pointing them at a designated environment instead of the default one, so new forms stop feeding the problem.
- Define a maker onboarding path, so people know where they are allowed to build and land in the right environment from the start.
- Review the default environment on a recurring cadence, because governance here is an ongoing habit rather than a one-time project.
None of that requires shutting down citizen development or slowing your makers down. It requires deciding where work belongs before the default environment decides for you. That decision usually sits inside a broader Power Platform consulting engagement, because the environment strategy and the DLP model both run on the same SharePoint data layer, which makes them one connected problem rather than separate ones.
Why this is a SharePoint problem too
This is as much a SharePoint governance question as a Power Platform one, because the apps in the default environment are almost always connected to SharePoint. Custom list forms create the apps. The libraries and lists behind them trigger the flows and store the data those apps read and write. The Power Platform layer and the SharePoint layer are not separate systems here – they are the same data with a different interface on top.
That connection is why treating this as “an admin will clean up Power Platform someday” understates it. An ungoverned app can reach governed SharePoint content, and a governed SharePoint list can be quietly powering an ungoverned app. Bringing the default environment under control is part of the same operating model that governs your sites, libraries, and lists, which is why it belongs inside the broader governance model rather than off to the side as a Power Platform footnote.
What to do now
Start with visibility, then close the front door. Before you migrate anything, these steps put you in control of the default environment rather than reacting to it:
- Inventory what is actually in the default environment today, including customized SharePoint forms and the flows tied to your lists.
- Run the Power Platform Advisor recommendation to move the eligible apps into a Managed Environment, and flag the shared-connector apps it skips for manual handling.
- Redirect new SharePoint form customizations to a designated environment so the default stops refilling.
- Set a review cadence and an owner for the default environment, so cleanup becomes maintenance instead of a recurring emergency.
Frequently asked questions
What is the Power Platform default environment?
The default environment is the shared Power Platform space created automatically with every Microsoft 365 tenant, where every user can build apps and flows without requesting access. It has no Managed Environment controls and only tenant-wide DLP, which is why unmanaged apps and custom SharePoint forms tend to accumulate there.
Why do custom SharePoint forms end up in the default environment?
When someone customizes a SharePoint list form using Power Apps, Power Apps creates a canvas app to run that form, and that app is placed in the default environment automatically. Flows built from SharePoint use the default environment as well, so routine list and form customization quietly populates it.
Can you move apps out of the default environment?
Yes. A Power Platform Advisor recommendation, generally available since April 30, 2026, identifies canvas apps and custom SharePoint forms in the default environment and moves them to Managed Environments, either manually or in bulk through automation. Only apps that do not use shared connectors are eligible through this path.
Does moving apps out of the default environment fix the governance problem?
Not on its own. Moving apps clears the current backlog, but the default environment stays open, so new apps keep landing there, and relocating an app does not resolve its ownership or data connections. The lasting fix is Managed Environments, a redirect for new SharePoint form apps, and a recurring review.
Should you turn off the default environment?
You cannot remove the default environment, and cutting off maker access entirely can break the SharePoint form and flow experiences that depend on it. The practical approach is to govern it: route new work to Managed Environments, restrict what the default environment can connect to, and review it on a cadence rather than leaving it open and unwatched.
Reviewed By
