Default Environment Routing - Yes or No?
Welcome everyone! This post is part of my wider series on how to implement low-code not just from a technology and process perspective, but also for a people enablement and adoption perspective to truly maximise value from the platform - This post gives an overview of the structured approach I’ve defined and how I’m breaking down my blog posts
Holistic Low-Code Enablement - Blog structure and navigation — EmPOWER Your World
In one of my recent posts I spoke about how we can create an Environment Strategy and use Managed Environments based on our Scalable Governance Model
In today’s post I’m going to build on top of that to explore Default Environment Routing.
In our previous model we categoried ‘Small’ as being low complexity, low criticality, low risk solutions and said that because of this, and that they should only be shared with a very small number of people, that we were ok with them being created in the default environment.
However controls on the default environment are limited if we don’t have org-wide premium licensing and can implement our Default Environment as a managed environment. So to manage things effectively we need to monitor and intervene (either manually or through automation)… What if there was a different way to provide some controls and isolate the work of developers so it’s not all in one big, lower controlled, environment… Enter Default Environment Routing!
This gives us a mechanism to create a dedicated managed developer environment for each maker to work in, rather than the default environment. And use Environment Groups (in Preview) to manage them more effectively and efficiently!
Microsoft Learn - Environment Routing
Microsoft Learn - Environment Groups (Preview)
Let’s take a look at how these might be used, how they might help us, and some of the interesting details associated with them.
We’re going to look at this from the perspective of an organisation who is primarily licensed using the seeded M365 licensing, and an organisation who is either premium licensed for their whole org, or at least for a significant proportion.
Standard Licensed Org
In this scenario we can turn on Default Environment Routing and our makers will be routed to their own developer environment. As we know these developer environments are ‘Managed Environments’ which would usually need a Premium license for all makers and users… However with Default Environment Routing we’re told that a maker doesn’t need a premium license to develop or preview their app in there…. But they do if they want to actually use it…
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.
So if a maker develops a Power App they’ll need to ensure it’s in a Solution, and then migrate it to another environment… Because they don’t have a Premium License in this scenario they can’t use the pipeline functionality they would get if using Managed Environments, so will have to create their solution (ideally a Managed one), export it to a ZIP file on their computer, navigate to their target environment (perhaps a dedicated small ‘Prod’ environment for them, or perhaps the default environment, or maybe into a Medium Prod Environment if it’s for use by their larger team? Friction… Barriers… Possibly frustration… perhaps enough to mean they won’t use that routed developer environment and instead just navigate to default and build and deploy there… In Prod? Defeating the idea of introducing some Application LifeCycle Management (ALM) practices.
The other complexity for them is that Default Environment Routing currently only works for Power Apps… I’m sure this will widen in the fullness of time!
Environment routing is currently limited to Power Apps only.
Premium Licensed Org
This is a very different case! Because our makers are Premium Licensed we can benefit from the wonders that Managed environments afford us and not have the frustrations that are present for the Standard Licensed Org!
Our Managed Developer routed environments can have restricted sharing, perhaps just to 1 so they truly are small ‘Personal Productivity’ environments, we could set up a ‘Pipeline Host’ and set up pipelines to aid moving those solutions into a Medium Prod environment with ease where they can be shared with a larger group of people.
Much more smooth and effective!
As these routed default environments are Managed Environments there are other benefits for both groups too! I’ve summarised these using the same format as in my previous Environment post linked to above.
Using Managed Environment functionality we can get a number of benefits:
For Standard Licensed Orgs
Limited Sharing gives additional control and management of risk associated to Business Criticality,
Using Maker Welcome content we can direct them to our self service SharePoint portal, or our community, to help them get support, understand the rules and best practices, and help on the processes they need to follow.
We can recommend, or enforce, use of the Solution Checker to improve the quality of what’s being developed and its accessibility to our users.
We can use Copilot to generate descriptions of our solutions to give our admins insights into what the solution is and what it does!
For Premium Licensed Orgs
As above plus…
Weekly usage insights for our top developers and information on the usage of their solutions to see if we may need to intervene and move them to a bigger class of environment
Use of Pipelines to aid in providing simplified ALM
Cataloging of high usage personal productivity solutions / those which are good examples of addressing typical business problem scenarios
Summary
So… Is default Environment Routing ready? Should I use it?
Well, it depends (in true consultancy fashion…)
If your organisation has a large number of Premium Licenses so all your makers can have them… I think it’s a no-brainer! There’s a lot of value and great ways to incorporate best practices and standard ways of working!
However if you’re primarily using the ‘Standard’ seeded M365 licenses it’s not so clear…
If you think the value and control that you’d get from it out weighs the constraints and added complexity and friction for your makers then the answer is probably yes! And even more definitely yes once your Power Apps AND Power Automate Flows can work in there in the same way!
But I suspect in most cases my answer is probably no at the moment… Developing your own solution and not being able to immediately use it feels a bit rubbish… I think having to use manual ALM export / import processes would just feel clunky, obstructive, and frustrate makers…
I’d love to hear your thoughts - and if you’ve deployed it already what sort of response you’ve had from your makers, and how it’s working for you!
If you find this post or any other of my posts useful please subscribe below to make sure you don’t miss out on future posts when they’re published! :)
