The Default environment has been with us since the release of Power Apps and what-was-then Microsoft Flow back in 2016. You can’t delete this environment and everyone in your organisation has access to build Power Platform solutions in there. It’s become an increasingly difficult area for admins to manage. You might have been a few years in getting to the Power Platform, but you’ll likely have some activity in Default already.
Finally, we now have an option to refer people away from Default to somewhere else. Enter Environment Routing… but is it going to solve all our problems? Let’s dig deeper into this feature and see what it’s all about.
Table of Contents
ToggleHow does it work?
When a maker navigates to make.powerapps.com, a developer environment will be created for them automatically. With the feature enabled, any future navigation to make.powerapps.com will divert them to their dedicated developer environment.
What's a developer environment?
As Microsoft’s article about environment routing suggests, they’re like a OneDrive for your personal Power Platform builds. I’ve long been a fan of developer environments; previously, I worked for an organisation that couldn’t commit to premium licensing. I therefore explored and learned Dataverse through a developer environment, which allowed me to gain skills I otherwise wouldn’t have.
Traditionally, these environment types allow users to build and run solutions with premium connectivity, without needing any additional licensing. This has been made available for some time now via the Power Apps Developer Plan. A maker can create 3 x developer environments this way too, to practice other concepts such as Application Lifecycle Management (ALM).
However, developer environments created via Default Environment Routing are created as Managed Environments. This means you’re ok to build & preview your apps & flows, but to run them you’ll need additional Power Apps and/or Power Automate Premium licensing. You’ll need this regardless of whether or not you have solutions with premium connectors.
However they’re created, developer environments do not affect your tenant Dataverse quota.
How to enable
Microsoft’s article covers the setup steps in good detail here. The image shown mentions environment routing as preview, when in fact it’s now generally available (GA). The account needed to enable this setting in PPAC will need the Power Platform Administrator or Global Administrator role.
It’s good that we can choose who we can route to a new personal developer environment – all makers or new makers only. In reality though, quite a few people in your organisation might already have at least one developer environment. That’s something to be aware of when enabling.
The maker experience
Let’s look at the Environment Routing feature from a makers’ perspective. In the examples below, I am ‘Test User 01’. With the setting enabled in PPAC, I’ve navigated to make.powerapps.com. Almost instantly, I’m greeted with this experience:
After a short wait (less than a minute), my new developer environment is ready and I’m instantly diverted to it. I can validate this in make.powerapps.com, by seeing the selected environment in the top right-hand corner:
I think this is a really cool experience. The fact that it automatically detects my presence in a specific domain, and then automatically creates a dedicated environment. That’s pretty slick.
As an existing maker, I might have to be wary of this feature too. I may already have a couple of developer environments created, either by myself or by an admin. As an existing user, I’d hope to be part of any communications for enabling this feature. Perhaps it should just be for ‘New makers only’ to avoid any confusion.I would also need to know about which developer environment I’m going to be automatically routed too, as per this extract from the documentation:
When working in my newly provisioned Test User 01 developer environment (that’s a managed environment, don’t forget), I’ll see the following message:
This is also a good experience and a nice reminder of where you are. As a maker with multiple developer environments, perhaps this could develop further to help show whether it’s of the managed or unmanaged persuasion.
Things to note
From both a maker and admin perspective, there’s a couple of things worth noting with Environment Routing. The full list is here and well worth digesting as part of your planning.
Licensing:
As mentioned already, developer environments created via this feature are a managed environment. Therefore, they’re subject to additional licensing requirements.
Access to the Default environment:
The feature doesn’t prevent access to the Default environment. Makers can still select this environment to build their Power Platform solutions. This is by design, as lots of functionality still lives with Default and so you can’t simply turn off access to it.
DLP policy coverage:
Developer environments provisioned with Environment Routing should inherit any existing Power Platform DLP configuration you have in place. Ensure a restrictive tenant-wide baseline covers any created, at the very least.
Alternatively, consider a slightly more relaxed policy to cover these environments to allow for experimentation. Either way, this needs to be a thought-out consideration before turning this feature on.
Power Apps only (for now):
The auto-provisioning of a developer environment currently only works for makers visiting make.powerapps.com. There’s no equivalent experience yet for Power Automate, Power Pages or Copilot studio.
My thoughts
This feature has been out for a while now, and I’ve purposely left it to settle before commenting. I wanted to take my time to see if my early impressions would change or stay the same. Spoiler alert – it’s the latter.
The good
Here’s what I love about this feature:
1- Routes makers away from default into their own dedicated space.
2- Promotes usage of developer environments because they’re awesome.
3- Saves admins work in manually provisioning developer environments for makers.
4- If your organisation already has a tonne of licensing, you’re good to use this feature right away!
The not so good
Here’s what I’m not so keen on:
1- Enabling this feature means I need to have existing premium licensing in place, or be ready to be backed with procurement of more licenses. This isn’t a requirement with the original developer plan environments.
2- Makers can build and test their solutions, but not run them. You can build, test and run solutions in the original developer plan environments.
3- Time saved for admins in not provisioning environments could be gobbled up by increased monitoring, cleanup and/or DLP movements of increased number of developer environments in the tenant.
The bad
Simply put, why create them as managed environments? I know it makes s£ns£, but does it make sense? It’s certainly a feature that would make admins lives a lot easier, especially for companies that can’t simply drop £000’s on additional licenses any time soon.
Instead, some are now looking at alternative ways to build their own environment routing mechanics. In the meantime, manually provisioning developer environments at request, or enabling the Developer environment assignment tenant setting, are more budget-friendly alternatives.
Let’s not forget, the default environment was something Microsoft gave us back in 2016. I’m sure they couldn’t have foreseen the difficulties it would provide some organisations, so to then provide a solution to the issue, then charge for it, is perhaps tough for some to swallow at present.
My summary
I hope the Environment Routing feature evolves and becomes more accessible to everyone who needs it. There are a lot of Power Platform admins out there, drowning in excess manual work and look enviously at basic governance improvements that they’re unable to make use of. From the maker point of view, building something you then can’t run just seems daft. That’s like giving me a Scalextric set with nowhere to plug it in.
There’s lots of potential with Default Environment Routing though, and I’m looking forward to seeing this being available for Power Automate, Copilot Studio and Power Pages. Encouraging maker enablement is hugely important.
So is it any good? If you already have the licenses ready to go – 100% YES! Otherwise, maybe not – at least not yet.
Thoughts of someone else
At this point in the article, I’ll bring in my friend and all-round epic guy, James Connelly. Here’s his current thoughts on Environment Routing, take it away James!

James Connelly
I'm a Power Platform Technical Lead for Network Rail. We're responsible for running, maintaining and managing the Rail infrastructure in the UK. We have over 42,000 employees currently, nearly half of which are monthly active users of the Power Platform. To date, we have around 8,500 apps & 20,000 flows that are active.
As an admin of one of the largest Power Platform users in the UK, the default environment is a problem. You’ll likely experience the same, no matter what size your organisation is. We currently have over 2,500 makers at Network Rail which is only going to grow.Â
Personally, I don’t think environment routing goes far enough to provide us with much benefit at present. Whilst this feature (and Managed Environments generally) are a great start, they don’t work for an organisation like us at scale. They don’t justify the premium investment on their own (I know that wasn’t the view of Microsoft anyway).
Let me explain why the current approach for routing doesn’t work for us just yet. Routing is good for people wanting to play around without contributing towards the ever-growing mess(?) of the Default Environment. As Craig mentions, it’s only for Power Apps at the moment and not for Automate.Â
Our organisation is currently split into several Regions and Central Functions. Our view is to give some visibility and control to the Regions/Functions (Business Units) but 3 developer environments doesn’t really give them that. Also, we don’t want Business Unit Leads to be Power Platform tenant admins.
What's my utopia?
We’re currently looking at a customised routing approach that better suits our organisational structure. This is part of a wider Power Platform strategy, where Regional/Function boards have more visibility about what’s being built in their respective Business Unit(s).
This approach would route a maker into their relevant Regional/Functional productivity or a ‘sandpit’ environment, based on what Business unit security group they’re a member of. We’d add them as a member to the relevant security group based on where they sit in our organisational structure/HR system).
How would that work?
We’re still completing the details but we would retrospectively do a large piece of work to move Regional/Functional Power Platform assets out of default and into their relevant Business Unit environments. Alongside, we’d like to automate adding new AD accounts to relevant security groups, using Power Automate.
The flow would then add the relevant security role to their Business Unit-specific environment structure. Alternatively, we’ll use Dataverse Group Teams to bind access to AD groups. Any automation could include a custom welcome experience to their Business Unit environment. This would introduce them to their Region/Function lead(s) and inform them about any Business Unit-specific governance.
The benefit of this would be that it’s default environment routing – but to shared environments. We’d prefer this over creating collateral with developer environments. It would also mean that makers can leverage the Power Platform toolset, right away, in the right environments. This would abide by the correct governance and onboards the new maker in line with our strategies.
To summarise
I love the concept of Managed Environments and there’s a lot of promise. However, there’s some way for them to go before they benefit an organisation such as ours. The current environment routing approach is a bit of a sticking plaster over the Default environment problem. I’d love to see routing to shared environments based on either a maker’s Department/Business Unit information in their Entra profile (or group membership) in the future. I’m a massive fan of innovation and empowering makers but there needs to be a balance. I’m just not convinced that the current approach for routing is quite there yet – but appreciate we have to start somewhere.
At an organisation that uses Power Platform at scale, there’s always slight unrest. Especially early on, with Security (info sec or similar teams), exec and other stakeholders in IT. Demonstrating to senior stakeholders that we have control and visibility of what’s being built can be challenging. We therefore need access to Managed Environment features and for them to evolve, so we can then justify the premium investment. It’s a bit of a chicken-and-egg scenario. I continue to be encouraged and optimistic about the additional consideration and funding that Microsoft are putting into evolving admin features, even if they’re not quite there yet, to fully bring benefit/justify the full premium price tag.
Thanks to James for sharing his insights into Environment Routing. From my work in the field over the last few months, it’s a common opinion; great idea, not quite there yet, tough to justify financially if you don’t already have the licenses.
Are you using this feature for your Power Platform estate yet, or are you planning on implementing soon? I’d love to hear from others experiences, so let me know in the comments below!
A very good read. I share the same opinion.
I am fortunate to work for a client that has a premium license for all employees and for them a development environment is worth it.
For other customers who can’t purchase a premium license for each creator, I use the COE kit, there is an app that allows the creator to request an environment.