In the last post, I mentioned the challenges of the default environment and why the environment routing was needed.
If you haven’t read that, please do read it and return to this post.
We often do things without understanding why. In this case, it’s crucial to understand the challenges before enabling Environment routing. Also, environment routing may not be for you, which is fine.
If you think it’s for you, then continue.
Okay, I assume you read the previous post and are happy to learn how to😀.
In this post, we will talk about how to enable environment routing.
All you need to do is four steps to enable the environment routing in Power Platform.
Enable Environment Routing
Step 0: Create an Environment Group and publish the rules.
The environment group acts as a basket where you can group all your environments and apply rules only to those environments.
If you’re lucky, at least one dedicated admin will be there to manage the Power Platform. Many companies might not have a dedicated admin at the beginning of their Power Platform journey. Power Platform admins might be working on other projects and managing the platform.
A few years back, there were no dedicated Power Platform admin roles. The good thing is it’s now changing.
You might ask, why do you need a dedicated admin role to manage the platform?
In a company, there could be 10s. 100s or even 1000s of people making solutions.
The admin is trying to help all these people develop solutions securely.
Also, admin is the glue between all other departments, such as the organization’s Security, Legal, privacy, and business teams.
Developer Environments:
Admin in most of the organization’s tenants, developer environments, and assignments will be turned off, which means only specific admins will create environments. This means that they will have less work to manage environments securely.
More environments = more work for the admins.
This is to stop the sprawling of many environments that get created.
A green icon appears at the bottom of Tenant settings, indicating that this setting applies to Managed environments.
We will talk more about Managed environment features in future posts.
Managed environments are premium governance features of Power Platform.
This blog post aims to talk about the challenges of governance on a large scale.
If you are starting with Power Platform, this post may not be important for you.
Are you still keen to read 🙂
Let us understand how people are developing solutions in the real world.
How people build solutions
Let’s take an example.
Alex is one of the company’s existing makers, and most people visit the maker portal (make.powerapps.com) to develop solutions using Power Platform.
Alex might have watched a video on YouTube or heard someone else say it is a great low-code tool.
Maker is someone who is developing solutions and solving business problems using Power Platform.
Whenever someone logs into the Maker portal, they’re automatically redirected to the default environment, and 99% of them don’t realize they’re in it.
Then, they start clicking on all the available links. That’s how any business user does it and develops those applications.
Once they build an app, they can start sharing it with everyone. Nothing is stopping them. This is a major challenge for admins.
People like Alex—let’s say we have 100 People now. All 100 people will develop solutions in the default environment and then share them with some larger groups or the whole organization.
Imagine you have 1000 People and 10,000 People doing the same thing.
That would be heaps of the solutions within the default environment.
Don’t get me wrong. It is good for people to develop solutions. The only concern here is they are doing it without knowing they are all in one environment.
There is also another challenge with this approach:
On the other side, many of the solutions that people are building will not be shared with the people, which means many of them will be unused.
Moreover, potentially, those unused apps and flows will die.
And as an admin, you’re the only person managing all this stuff.
Once you get more active users, because you want everyone in the business to be involved, try to build solutions and solve the problems within the company.
To summarize, below are the challenges with Default Environment
Everyone in the org can build solutions.
Unused Apps and Flows.
Can’t delete the environment
Did I miss anything? (Please add it to the comments)
Microsoft’s product team understood these challenges and suggested some of the best practices.
Best Practices
Rename the Default environment to personal productivity.
That means you are telling people to use the Default environment only for personal solutions. Do not build solutions for your department or company.
Many people don’t realize that they have multiple environments. As soon as they land in the default environment, they click these buttons and start building solutions.
Renaming the default environment to Personal Productivity is still a good practice, but it doesn’t stop people from building solutions.
The other best practice would be restricting the connectors within the default environment.
Minimum number of connectors
You can minimize the number of connectors available in the Default Environment.
You could choose only the standard connectors, giving you more control.
This would reduce the number of solutions created to a certain extent, but it would not solve the problem.
Cleanup the orphaned solutions
You need to clean up some of the flows or the solutions that are not being used.
Either using automation or creating a process.
This needs to be an ongoing process to keep the environment tidy.
Reactive monitoring of solutions
All these best practices are somewhat reactive to what’s happening.
So what is react to governance?
Reactive Governance
Once makers build applications, they can share them with large groups and everyone in the organization.
And makers might not follow the guidelines. Deploy those solutions without any quality checks.
As an admin, you use tools like the starter kit, review those solutions, and then ask the makers for more information.
Why have you shared with everyone?
Can we use a different environment for different processes?
You should have followed these things.
And did you check our existing guidelines?
As an admin, you react to everything that has happened before.
It’s easy to react if you have few makers within your organization or even 100 of them.
But let’s say you have thousands of them, building many solutions. There is a limit to reactive governance.
That’s one of our significant challenges, especially if you have a large user base.
In a nutshell, Rective governance is:
First Makers:
Shared solutions with large groups and Everyone
Not following the guidelines for High impact solutions
Deployed solutions without quality checks
Then Admin:
Review solutions and ask makers for more Info
Provide the guidelines and process that need to be followed
If something breaks, check the quality of solutions and help in remediation
Also, you need to understand the path of the platform’s admins.
How did they become admins in the first place?
Everyone’s Path to administration is different
In my case, I studied Electrical and Electronics, then started working on.Net and SharePoint.
I was introduced to the power platform early in 2018, and now I know a bit about it.
However, most admins come to the power platform from different backgrounds.
Some admins end up with the Power Platform because they manage other platforms, such as SharePoint. They’ll end up supporting or managing the Power Platform.
Also, in the early stages of a company, people start using a platform without noticing they are using a power platform.
When I say without noticing, most of the SharePoint and M 365 have a baseline license, so they could build solutions using those licenses.
You may not see much growth, or many other teams will build solutions.
The growth would pick up slowly after a few years. If you started in 2018, for example, and it’s been five to six years, you will see more growth in Power Platform.
How to manage the growth of these applications?
Or
How do we even know there are applications within the platform?
Challenges with Starter Kit
There was no CoE starter kit before 2019. You need to run PowerShell scripts to get the platform inventory.
The Microsoft team released the kit in 2019, and everyone can see what exactly is in the tenant.
There was always a surprise when they installed a starter kit.
Before the starter kit, it was always like they lacked visibility.
The visibility of all the Platform components helped many companies to plan and adopt the Power Platform accordingly.
The starter kit also improved quite a lot over the years.
If I’m not wrong, it’s been over five years, and many features have been added.
One of the standard apps in the starter kit is the Power Platform admin view app. It’s one of my go-to apps for the admins to understand the applications built by makers.
When I tried installing the May 2019 version, it got only 100 objects within the code solution. In 2024, they got over 400.
That means it’s pretty much the starter kit grown more than four times.
The other day, I was trying to automate the enrollment request process, and we were trying to add environments to the DLP. I struggled to automate the process, and my teammate said there was already a flow that added enjoyment to DLP. So why not use that? It is always quite challenging to keep up with the changes.
With the Microsoft team releasing the new features in the starter kit, you need a dedicated person to manage the changes and everything else that happens. It’s pretty challenging.
In short, below are the challenges:
Reactive governance
Upgrade and maintain tool kit every three months
Keep up with the changes to the tool kit
Platform Growth
In the future, with AI and copilot, everything happening will allow people to create many of those solutions, apps, and flows with prompts. Can you imagine how much growth is going to happen?
I might be guessing (who knows the future??)
Whatever we have seen in the last five years could happen in the next one or two years. This slider can be moved towards the extreme side.
I don’t know, but it depends on adoption. It’s always better to look ahead.
With all these challenges in the default environment, you might be better off planning using Environment routing features.
Summary
In this post, we have discussed the challenge with the Default environment at a large scale.
Even with best practices from Microsoft, managing the default environment is challenging.
The starter kit does help us understand what we have in the tenant, but it is still a reactive governance approach. Managing solutions is a big challenge, especially with hundreds or thousands of makers developing solutions to solve their problems.
Environment routing aims to solve governance challenges on a scale.
Note: Environment routing is part of the managed environment feature, which means it is premium.
In the next part, I will show how to start with Environemnt routing, groups and rules.
Are you using Managed environment features? Please let me know if you have any comments or feedback.
– Why Manage environments and most importantly when to enable. – What is available now – Preview features – Starter kit and how it works with Managed environments And a demo of how it all works together.
As you read, a starter kit will be an integrated part of managing the platform and other tools such as PowerShell and BYODL.
Based on the content planned, is there anything else I should add?
With the release of the groups and rules (Preview), it is important to consider the developer environments as part of the strategy.
Below is the list of pros and cons(Limitations).
I also added a few things you need to take into consideration.
Pros
Every developer environment comes with a message that indicates the purpose of the environment.
When the user tries to share the apps, it shows the below message to the App owner.
Users can create up to 3 developer environments. If they start developing solutions, you don’t have to manage/provision for them every time.
Newly created developer environments can become managed environments. This is to support the environment routing. This feature is currently in preview.
With routing, you can apply preconfigured settings such as Sharing Limits, Solution Checker, Usage Insights, and Maker welcome message.
New makers don’t need to know which environment they need to work on.
Cons (Limitations)
You will have less control over the naming conventions of the environments.
Flow runs/month (750) and capacity limits up to 2 GB.
Environments created using the Power Apps Developer Plan that have been inactive for the last 90 days will be deleted after the environment owners are notified.
There are a few more things to consider
You must enable Tenant level settings (Developer environment assignments) to leverage the developer environments.
You do not need to make default as a managed environment to enable the routing.
All developer environments created through environment routing are managed environments, as are all environments in a group. These environments require premium licenses to run Microsoft Power Platform assets.
Please create the comms to communicate the consequences with users, which will help you manage it properly.
Developer environments add more values once the environment routing becomes GA.
In the last post, I shared 10 things to consider before installing the CoE starter kit.
If you do not consider those things, you will have a lot of issues managing the starter kit.
Also, people make common mistakes while maintaining the starter kit.
I have made some of these mistakes and seen others make similar mistakes.
Hopefully, after reading these, you can learn from our mistakes and not repeat them.
But you need to ask why they are happening.
Why are mistakes happening when upgrading the CoE starter kit?
The starter kit is not a simple tool to manage.
Here is why.
We are trying to automate the environment request process.
I was struggling to automate adding environments to DLP.
I am trying the Power Platform admin V2 connector action.
But my teammate said we have it already as part of the tool.
I was like what? How did I miss it?
Then we used the child flow to complete the automation.
You might have faced similar kinds of challenges.
To put this in context, how large was the starter kit?
At a high level, there are three main components
1) core components
2) Audit or Governance components
3) Nurture components
I am ignoring the other one for now (Innovation backlog). This component didn’t get much attention.
As of April 2024 release
Core components got
423 Total Objects
49 Tables
15 Power Apps
110 Cloud Flows
63 Pages
Audit components
42 components
1 Table
3 Power Apps
12 Cloud Flows
8 Pages
Nurture components
74 components
15 Tables
3 Power Apps
8 Cloud Flows
7 Pages
Note: I will try to update this metric once a quarter. Let me know if you read this article in the future and it hasn’t been updated for over three months.
Starter is a great tool that adds value to managed environments.
But it needs effort from the Power Platform team to manage it.
It is easy to make mistakes if you do not know what you are customizing.
If you do not know how to use the kit efficiently,
Now you know why. Let us get into the list of these mistakes.
The list below is not in any particular order.
Immediate CoE starter kit upgrade Post-Release
The starter kit team releases the updates once a month.
If you upgrade to a new release without waiting for initial bugs to be identified and fixed. It can cause issues if there are any critical problems present.
Give yourself a few days to a week to check that the kit updates are not significantly flawed.
Not doing Testing
Not testing newly released components in the development environment before production use can introduce unexpected issues.
This happens mainly because of the lack of a dedicated development environment.
You need to have a development environment to test the released updates.
If you use any email functionality, enable an admin account email and start testing with a few users. Make sure the emails are working as expected. You do not want to email everyone in the organization even by mistake.
Overlooking Starter Kit’s Full Functionality
Failing to invest time in understanding all solutions and components in the starter kit can lead to building custom solutions that are not required.
Make sure you give yourself time to understand all the components. If not, you will build something not required.
Not updating the starter kit frequently
You must update the CoE starter kit at least once every three months.
Otherwise, managing the starter kit may experience many unexpected issues.
It’s even better to upgrade the starter kit at least once every two months.
Document everything, and this makes it easier to do future upgrades.
Too many customizations and not having conversations with the Starter kit team
People customizing the starter kit functionality is common.
While customization, it’s always better to be in touch with a starter kit to understand the roadmap rather than building a custom component.
The component you are building might already be planned in a few months, and then you can always wait and focus on other areas.
It answers some of the important questions about the platform and people.
Who is developing solutions?
Where they are developing solutions?
How many solutions?
It also answers many other questions about your Power Platform’s current state.
Why checklist?
I have installed/upgraded starter kit over 60 to 70 times in the last few years for multiple tenants.
If you are wondering how come these many times I installed/upgraded?
Last year alone I installed/upgraded over 20 times in Development and Production environments.
I am also responsible for managing the starter kit in my current role.
The checklist helps me avoid mistakes whenever I install/upgrade the kit to a new tenant or maintain the current one.
The goal of this post is to avoid the mistakes you might make.
Below are some key elements to get the starter kit up and running.
Note: This is not a complete list, but having the checklist prevents me from making mistakes later.
1. Cloud export vs BYODL (Preview)
Cloud Export
If you are a small org, you should use Cloud Export.
If you are starting, this option should be used regardless of the number of people using the platform.
BYODL (Preview) – bring your own Data lake is still in preview
It was introduced to support extensive usage and speed up the inventory process. For whatever reason, it is still in preview.
In this guide, I will talk only about the Cloud Export option.
2. Environments
You need at least two environments to start the installation.
Make sure to configure the settings below in each environment.
This can be done from the Admin command center App.
Development environment
FullInventory = No
ProductionEnvironment = No
(This setting prevents people from receiving emails)
Production environment
FullInventory = Yes
ProductionEnvironment = Yes
Optional – You can also use the UAT environment, but it’s overkill.
3. DLP Policy
Create a dedicated DLP policy.
Given the number of connectors needed to get the starter kit up and running, it’s always recommended to have a dedicated policy for CoE.
Make sure you are allowing only starter kit Development and Production environments. Not any other environments.
4. Service account
To configure the starter kit use the service account option.
This is one of the mandatory requirements for the kit to be up and running.
It’s the backbone of platform governance and administration.
You should not use the individual user account, and if the person leaves the org, you will have to configure the kit again.
This should be mail-enabled so you can receive emails when flows get errors.
5. Licensing
The Cloud Export option needs a minimum of the below licenses.
Make sure you assign these to the service account.
Office 365 E3 (minimum)
Power Apps premium
Power Automate premium
Power BI Pro or per capacity.
6. Office 365 Groups
A makers group is necessary to add people building apps to this group.
Ensure you disable the setting that sends a welcome email when a person is added to the group. Otherwise, people get Spammed when they are added to the group.
You could potentially add the people to the Yammer group as well.
7. App registration
Create an App registration in the Azure portal with sufficient permissions to get the Audit Log info.
8. Documentation
Before you start the installation, start documenting everything.
While you are installing, take the screenshots (Before and After).
Make sure you capture all the steps while installing the kit.
If you get stuck, take a screenshot and capture the error logs.
Once you fix the issue, come back and update the doc with the root cause.
Repeat these every time you upgrade the kit.
This will save you hours and hours.
Also, maintain the details on what version you are installing, the status, and when you installed it.
This helps you track the components you are installing and upgrading.
9. Be Patient
Your tenant’s full inventory could take 24 to 48 hours, if not more. Relax and wait for the flows to complete the initial inventory.
10. Validate
Power Platform Admin view
Open the app and see if the data is getting populated for all the components.
Admin command center App
If you need help getting inventory.
Open this app and check for the Inventory Tab under cloud flows, see each flow’s status, and ensure everything is running without failure.
If there are any failures, fix them or raise a bug with the starter kit Github repository.
Key Notes
You do not have to install and configure all the components.
Start with core components.
And
Most importantly, do not enable all flows, especially the ones that will send emails.
HELPER – Send Email
Adding users to the group
Leverage wizard
You can install individual starter kit components using the Starter ki wizard app.
Again, do not enable all the flows( You could potentially SPAM all users in the company).
Final Thoughts
The CoE starter kit is the backbone of understanding why, what and where.
Also, the critical thing to know is that the Starter kit itself is not enough.
You’re mistaken if you think you have a starter kit and everything is done.
It is just a starter kit and you need more processes and systems to manage the platform.
You need to work with people to create those processes and systems.
CoE starter kit # CoE
Next up, we will talk about common mistakes made by admins while configuring the starter kit.
Is this checklist helpful or do you have a question?