Previously, we’ve looked at the Power Platform Centre of Excellence Starter Kit. It has a key role to play in giving administrators useful insights into their estate. One of the questions that comes from installing the kit, and in general is: “How can I get users out of the Default environment?”
This is a key question to ask, especially if makers have already built and shared lots of apps from here. It’s also important for crafting an effective environment strategy for your Power Platform solutions.
Before we get there though, let’s look at this environment in more detail. We’ll also look into alternative routes for makers to get making.
There are new people coming into the Power Platform administration role all the time. Chances are they’ll already have activity in the Default environment to unpick, unaware of what it is or why it’s there. So, let’s take it back a bit and cover a bit of history.
The year is 2016. Power BI has been floating around for most of the year and has shaken up the analytics world (unless you were using Qlikview or Tableau, in which case – as you were!). Towards the tail end of 2016, October 31st to be precise, PowerApps as it was back then (without the space) moved into GA – General Availability.
To coincide with that, two other things went into GA:
1- The Power Platform Admin Centre (PPAC).
2- The Default environment.
What is the Default environment?
It’s a single environment that’s automatically created for each Microsoft 365 tenant. This environment is available to everyone in your organisation. You can’t delete this environment, you can’t turn it off, you can’t stop people from using it.
Everyone has the Environment Maker role, meaning they can crack on building Power Platform solutions right away. Any new starters in your business? Yep, they’ll get instant access too. No need for a license at this stage either, there’s a massive pot of free ones and will be auto-assigned.
Back in 2016, the company I worked for had concerns. “Why have Microsoft given us a tool we can’t administer properly?”.
The Head of Architecture & a key figure on our Design Authority had concerns that people would use the Default environment to try and replace line-of-business systems (he was right, people did try to do that, it was a nightmare). As a result, myself and a few of the Microsoft 365 team jumped on call with the Product Managers at the time. We challenged when there’d be sufficient administrative capabilities (ie via PowerShell, Graph, or extending PPAC) so we can monitor usage of Default.
“Part of our vision is to allow anyone in the business to streamline business processes, without going through IT”.
I completely understood this and I bought into the vision (I still do), I don’t think even Microsoft could have guessed how much grief the Default environment would give businesses since then.
Back then, we didn’t have a CoE Starter Kit to answer our prayers either!
An unrelated note, the original PPAC UI, ewww. Glad it’s improved since!
How do we manage it?
So, you have this rogue environment that anyone can access and you can’t get rid of. How do you manage it? Microsoft have documented some good recommendation here, but will break down with our own experiences below.
Rename default
A common step, also recommended by Microsoft (here) is to rename the Default environment to something more pertinent to your business. We typically see businesses follow Microsoft’s steer & rename to Personal Productivity. We’ve also seen other combinations such as Personal Development, Company Dev or other such wonders.
This is a good place to start to help makers know of the environment intentions. A rename won’t stop them from building in there though, which is where the next recommendation can help.
Guidance and strategy
As part of your environment strategy, you’ll need to decide what you want to do with the Default environment. What solutions can be made and where? What thresholds should be triggered? How will things be monitored?
A simple model for this might be Microsoft’s articulated approach. This is focusing on number of users, nature of data, business impact & ALM requirements. Note that Default is recommended for minimal users, open data, low monetary/business impact and doesn’t require Application Lifecycle Management (ALM).
What I believe is becoming a more common approach (and one I both use and advocate) is a T-shirt sizing model. Personal solutions – a Small, can happily sit in the Default environment but those XL ones, yeah they’ll need their own environments, policies, ALM and more.
Ever checked out Simon Owen’s blog? If not, you’re missing out! He articulates concepts really well with his own drawings/tables, governance is no exception. You can see Simon’s use of sizing to drive governance in one of his latest articles.
CoE Starter Kit analysis
To help inform your environment strategies, analysing and monitoring what’s been made in the Default environment is important. In our previous article, we covered one of the report pages where you can drill down into app activity per environment.
Are any apps shared with more users than your guidance for Default environment apps?
How many unique users are using the app & is that over your set threshold?
Has it been launched recently & therefore active?
You can usually tell from the name of the app, its maker, or who it’s shared with what area of your business it relates to. Ask the same questions of the app as above (sensitivity of data, impact, no of users) and/or t-shirt size it. You can then determine what dedicated environment the solution needs to live.
By the same token, you can use the CoE Starter Kit to identify apps/flows in Default that are orphaned or unused. You can clean these up (aka, throw in the virtual bin) to help keep Default tidy. Make sure you communicate first though!
Communicate
You’ve renamed the Default and have your strategies in place, but won’t mean a lot unless you communicate with your makers! One of the key things you can do here is create an internal Power Platform hub. This could be a SharePoint or Teams site that houses all your key information about the Power Platform. This needs to be part of your plans irrespective of what you’re doing with the default environment.
A great resource you can deploy here is the Power Platform Hub Template. The template will give you a SharePoint site with some pre-baked content that you can configure to your own needs. You can choose to build your own from scratch if preferred.
On the link provided, there’s some tips for what your hub should include. They’re good starting points but, in our experience, it’s worth expanding what’s on your Hub. This will be helpful to onboard new makers and keep the more experienced ones informed too. Part of this will be around your internal best practices, such as what environment(s) makers can build in that aren’t the Default environment.
Developer Plan
The recommendation for Default is a personal productivity space; build apps & flows that’ll help you personally. You could however choose to advocate the Developer plans for this instead. These environments are for individuals to build personal solutions. It can also be a safe space for makers to spin up proof of concepts, that may make their way into a wider, more productionised state in future.
The cool thing about the Developer plan is that it will give individuals access to Dataverse and all other premium connectors. This is important, especially if your company is still using SharePoint as a backend. It gives makers the chance to get familiar with Dataverse and help build justifications for wider usage.
To re-iterate, these environments give makers premium services WITHOUT any additional Power Platform licensing required. I stress without, because it’s important for later in this article.
The flipside for admins is, how do you allow these to be created? As per the tenant setting, anyone can create a Developer environment or only specific admins:
Also consider how you’ll monitor these (best place is likely via the CoE Starter Kit). Some may be provisioned and not used, so consider a routine cleanup or gentle email to the relevant person. A developer environment that’s inactive for 90 days will be deleted automatically, apparently, though I’m not sure I’ve ever seen this as a reality (happy to be told otherwise!).
If using developer environments, make sure your tenant-wide DLP instantly gobbles these up to provide the relevant data protection. You could even have a more relaxed DLP policy for these environments, depending on the scenario.
That all sounds great...
… but none of those methods will actually stop anyone from building in the Default environment. Some may miss or ignore the comms, or simply want to do it a certain way because “that’s how we’ve always done it”.
For most, taming the Default beast is a lot of additional effort. Maybe there’s a light at the end of the tunnel?
Default environment routing
Default environment routing is a feature currently in preview at time of writing. Be careful to use in a production setting for now. You can see the documentation for this here.
The good
The design here is that, with the setting enabled, when a maker visits the Default environment for the first time it will provision them a new developer environment! How cool is that… right?
The bad
There’s a slight issue here though: Developer environments created this way are done so as Managed Environments. Managed environments are not included under the Developer Plan, so users will need a Premium license to run any of their own apps or flows.
“But they’re not using any premium connectors”.
That may be the case, but Managed Environments are a premium feature, so you need the relevant license to consume the premium environment features. Let’s say you have 10,000 people in your organisation, up to 10,000 people could create a developer environment this way, so you’ll need a pool of licenses ready to go.
The ugly
Before I get on my soapbox about this, I want to clarify that I’m a HUGE fan of Managed Environments. They have some really good functionality that will help organisations streamline & improve their governance operations.
With that said, we remembered earlier that the Default environment was bestowed upon us by Microsoft back in 2016. Admittedly I don’t think they could foresee the difficulties it would provide companies, but they’ll have been WELL aware of them in the years since.
In some ways, this solution feels like this to me, and a lot of companies and admins I’ve spoken to recently:
“Hey, we’re sorry we gave you the Default environment. We know it’s been a pain for most of you for a long time. We’ve now got a solution to the problem we gave you, but you gotta get your wallets out or carry on doing things manually”
Away from the financial side, Developer environments created this way will still need managing, with good monitoring in place. Unused environments still need cleaning up, but now with the added overhead of having to unassign a license if they’re still seen as a luxury purchase.
Kinda feels like a hydra moment…
Maybe it'll change
I fight a lot for the underdog, I always have. The UK economy recently has been tough, as such business budgets have been tighter. It’s more important than ever for such companies to improve digital offerings internally but licensing constraints will make it difficult for some. Meanwhile, that sole Power Platform developer-who’s-now-been-made-an-admin is drowning in manual work and desperate for someone to throw them a lifeline.
I hope this feature will be more accommodating to such companies & admins, because it’s a REALLY good idea for managing Default environment usage. I just think the implementation could be better & more inclusive.
Recommendations
If you have the budget, definitely investigate Default environment routing. BUT, it’s currently in preview, meaning you shouldn’t use this in a Production setting. So unless you’ve got a test tenant knocking about somewhere, erm…
Environment strategy is so important, regardless how you manage Default (we’ll be covering environment strategies next week). Managed Environments can form part of that strategy but perhaps more so for those larger solutions that will need full ALM and other premium services. Communications, evangelising and bringing people together will also help spread the strategies & best practices you’d like to put into place.
At the end of the day, we recommend all the above ways to manage the Default environment. With or without environment routing, you still need to actively monitor activity, nurture makers, share important things on your intranet, use the Starter Kit and build flows to help with bespoke needs.
The default environment isn’t going away and whilst there’s no “quick” fix, there are a lot of options to help you.
Do you have any ways to manage or monitor the Default environment that we’ve not mentioned above? Let us know in the comments below!
Thanks for reading. If you liked this article and want more helpful insights into life as a Power Platform Administrator, don’t forget to follow us on socials 😊.
All articles in this focused series will be curated here. Feel free to add it your favourites for your one-stop-shop for all your Power Platform Admin needs. Is there a topic we’ve not covered? Reach out to us and let us know!
Michael’s Blog, Twitter & LinkedIn.
Craig’s Twitter & LinkedIn.
MS be like I will create the problem and then offer solution for money 😀