We already discussed the two main pieces of managed environments. Besides the Pipelines and Catalog, there are a bunch more things that Managed Environments bring. In this closing chapter we will highlight the thing I think are of interest.
Challenge Objectives
🎯 Finalize the Managed Environments trilogy
🎯 Learn about the smaller but valuable features
🎯 Get my thoughts on how to make Managed Environments a no-brainer
Introduction
As it is our closing piece with multiple smaller features, we will run through them fairly quickly.
Features
Limit sharing
The idea of Limit sharing is really interesting to me. By default, when a maker navigates to make.powerapps.com, they will end up in the default environment. One important aspect of the default environment is that everyone within the tenant will have access to this environment. That's why this environment normally has the strictest DLP applied. That absolutely gives some peace of mind.
From my experience, this setup still leaves us with two main issues. The first is that we can end up with Power Apps built on SharePoint, that have hundreds or even thousands of users. Too many times I've seen issues with such an app because an unaware Site Admin removed a column or the entire list. Business critical is maybe a bit too much, but we can call it business important. We want a bit more control on these types of solutions.
This is exactly where Limit sharing can come in handy. Within an environment, we can cap the amount of users an app is shared with. If a maker tries to go over that threshold, he will be blocked. The image below is from the documentation where it shows the error message.
For complete new tenants this can be doable, but for tenants that already have many Power Platform assets within their default environment, it might be hard to accomplish. We will discuss this topic later.
Default environment routing
The second issue that we will have is flexibility. We probably blocked premium connectors within the DLP allocated to the default environment, just so the license consumption will not skyrocket. What if the makers want to use a premium connector because it connects to some third party software that is common within the company? At my current client, JIRA is one of those connectors. So, what should we do?
In this case, some form of Advanced Citizen Development environment will come in handy. We might start with allowing one or two additional connectors, but this number will grow over time. Eventually we will end up with an environment with many advanced citizen developers that can use all of those different connectors. You definitely will want more granular control.
This is where default environment routing can come in handy. When turned on, makers will be routed to a Developer Environment that will be created instantly. These are also called Personal Environments. I like the OneDrive analogy. OneDrive is a Personal SharePoint, mainly to store files for personal use and the occasional share. This is exactly what we want from these Personal Environments.
The big advantage of this is that when a maker requests a connector, we can adjust that single environment to allow it, while other makers won't have access to it within their Personal environment. This gives us all the flexibility we need.
Personal environments created through default environment routing will be managed and preset to a sharing cap of 5. If it's required to share it with a broader audience, we can utilize the Pipeline functionality. It is also good to be aware of the fact that this routing is only done with Power Apps. Not Power Automate or any other product.
The fact that developer environments are used for this functionality raises some questions. The purpose of the developer environment is for development and test purposes. Apps and flows with premium functionality will just run, although with some capacity constrains. I would argue that personal use will be production when used regularly. That's probably why these are made managed, which will require premium licenses. For the scenario where we will use these Personal Environments to granularly control premium connectors, this obviously isn't a problem.
Environment groups
When environment routing will be used, your number of environments will increase significantly. To manage these environments, you can use something called Environment groups. Currently, this will allow you to set the rules, just like they are available within managed environments. Currently these are:
Limit sharing (discussed earlier)
AI-generated descriptions (next section)
These are helpful settings and will make maintaining all these Personal Environments easier. I do have to say that we could use much more setting options here. We would like to set the DLPs for these groups here too, so this is handled automatically. It would also be very helpful to link a pipeline to it. Just so we don't have to add a new Personal Environment to an already existing Pipeline and adding it as a development environment. Some environment settings (mostly from the Features section) would be welcome too. Some examples are AI Builder preview models, Copilot features, Hosted RPA, PCF for Canvas, Ideas, etc.
This is a relatively new feature, but has some true potential. It just needs a bit more capabilities.
AI-generated descriptions
This is a pretty straightforward functionality. It will generate an app description for you. With all the Copilot bonanza going on, this might not sound like a big deal. But from an admin perspective, it could be. When I crawl through the CoE kit, it's actually pretty time consuming to understand what an app actually is doing. The used connectors give some input, just like the name itself. But the available information is usually quite limited.
All additional information would probably help quite a lot. The CoE kit has the Command Center app, which asks makers to enter their business justification, As this is premium, I don't see this being adopted very often, but Managed Environments are premium too, so we can compare them.
Still, I think the auto generated descriptions could be of value. especially for the things that will stay within the Personal Environments. For the solutions you deploy to production, you might want to adopt the Command Center, as this will add much more quality and value.
Minor detail, US and English only. I guess this will improve over time.
Conclusion
I think by now it's time to actually confront the elephant in the room, licenses. I totally get that Microsoft want to sell licenses. To keep such a platform up and running and add new functionality just costs money. I also totally understand that client are reluctant to go all in, as that is kind of the current proposition.
We are sort of gridlocked in this situation. To overcome this, I think there is work for both sides. Let's start with the unpopular one. To put it bluntly, we just shouldn't be cheap. Quality costs money. All budgets are so focused on the actual currency value, but it's not always as clear what the return on investment is. Yes, there are some initiatives for this to indicate it on a solution level, but administering the platform costs time. Every single thing that can reduce the admin time is great. I would prefer to throw the money at licenses that will bring admin features (and oh, by the way, can create premium solutions with lots of value) rather than throwing money at an admin person (which I am myself).
I also think Microsoft should do something. The first thing I would like to see can easily be achieved I think. I would like to have Managed Environment capabilities on the default environment without making everything premium. Just the default environment. This way we can actually make the default environment controllable, without too much monitoring and cleanup work. The collateral benefit is that solutions with more users will need to be hosted in a different environment. To get it there, it will be a no-brainer to utilize the Pipelines in Managed environments. As that is premium, there will be less incentive to create SharePoint apps, which are always a bit tricky to maintain in my opinion. I absolutely think this will lead to more licenses being consumed, better solutions being built, and a better platform posture. An absolute win to all of us.
It will enable us to actually go all the way with managed environments, as there is still a decent location to properly host the standard tier apps and flows, and route makers to their personal environments for premium stuff, which are managed environments. Makers can use Catalog to quickly reuse company components, and deploy their solutions with Pipelines. Absolutely magnificent and I can't wait for this to become a reality.
Then there is one more thing that I think is crucial to make enterprises instantly want this. We need to somewhat merge the Power Apps and Power Automate license into one. It's just such a hard message to convey that when they buy a Power Apps license, they also need a Power Automate license.
In some cases. Power Automate flows that are running in context of a Power App can be app associated and therefor are included with the Power Apps license. Simple SharePoint to Jira requires the additional license for Power Automate. This is such a mojo killer, as this is exactly the scenario for the Personal Environment. Limit the API calls, remove RPA from it, limit. That's all fine. Even the developer environment cap of 750 runs a month is not an issue at all. Just give us the power to create simple apps and flows in the Personal Environment with 1 single license.
If we get there, I will cry of joy.
Additional Information
If you have created some Managed Environments and want to redo this, you will need to use the PAC CLI. There is no way yet to do this is the Admin Center unfortunately. If you haven't used the CLI before, Install it by installing the Power Platform Tools extension for Visual Studio Code. Then you can create a new terminal and run the command below (after you update the environment GUID).
pac admin set-governance-config -env 00000000-0000-0000-0000-000000000000 -pl BasicYou can create different pre-export step flows for different solutions, pipelines, or stages. You can achieve this with Trigger conditions.
Key Takeaways
👉🏻 All the smaller features combined will make admin life much easier
👉🏻 If adopted, this will change your environment strategy completely
👉🏻 I can almost recommend using them. We're nearly there