As your organisation embraces new tools, you’ll find yourself managing multiple environments, each serving a distinct purpose. To foster growth and efficiency, it’s crucial to develop a robust Power Platform environment strategy.
There are lots of different opinions and approaches to this. You might find common themes across different opinions but also completely unique takes to environment strategy. There are also lots of factors that will determine the outcome. Our goal with this article is to highlight some of our approaches that have worked well – but they’re by no means the gospel!
A Power Platform environment strategy can take various forms, tailored to specific business goals, project requirements, data types, and/or legal considerations. There’s no universal solution—every business is unique and requires thoughtful, individualised planning.
As always, Microsoft cover this topic well, our aim with this article is to inject our experiences too. We’ll discuss various approaches, themes and concepts, and how to get started.
Start with your data
When it comes to anything technical – always start with your data. Whether it’s building a solution, integrating business systems or crafting a Power Platform environment strategy, data is key. It should always be your starting point as it covers lots of things to consider:
❓Where do we need to store our data❓
❓What data will we be storing❓
❓Who needs access to that data❓
❓What other data sources or connectors will my solution talk to❓
Just these questions alone can spark potential avenues to explore for initial environment strategy works.
Regional data
Some companies may operate over multiple countries. Whether they have multiple tenants or a single one, consider what data you need to store in your environments.
When creating an environment, we can choose the region for the underlying data. This determines what data centre our solutions are deployed to:
Many countries have laws around where you can store data. If you have users across the globe, you may need to deploy duplications of environments. This will aid optimal performance by keeping the data local to the user group, whilst supporting data residency requirements.
Multiple tenants & environments have plenty of other considerations too. These are well documented by Microsoft if you need to find out more.
Types of data
Types of data is always an important factor. High value or extremely sensitive data is likely to need its own environment (or set of environments). This will also allow for more granularity for who has access to the environment and what access they have.
This not only helps dictate a future environment strategy, but also how it evolves. Try not to mix sensitive data types in the same environment, keep them ringfenced. In some cases that will mean creating one or multiple new environments to maintain integrity & access.
Access to data
This usually goes hand in hand with data types. Access is much easier to manage when your Power Platform environment strategy sensibly segregates data. This is sometimes a driver for new environments:
“We need to capture this data, but only X, Y and Z should be able to see it. Our existing environment is accessed by others who shouldn’t see this new data set”.
For both data types and access, you can run everything from a single environment and ensure your security roles are TIGHT. I’ve personally found this to be a bit more of an administrative headache though, so separate environments can make things easier from a security perspective.
Connecting to data
Connectors are the API wrappers we use to communicate with data sources in the Power Platform. We can drive what connectors our makers can and can’t use using Power Platform DLP policies. This means we can have dedicated policies for dedicated environments, allowing us to provide services to some but not others, avoiding potential data leaks or reputational harm.
When we talk digital guardrails for the Power Platform, DLP is very closely aligned to environments:
1- A data loss prevention strategy will impact an environment strategy.
2- A Power Platform environment strategy will impact a data loss prevention strategy.
Let’s say we have an environment cluster that covers just the base use of connectors; SharePoint, Teams, Office 365 Outlook etc.
A new requirement for that business area requires accessing a connector that’s excluded from the environments policy. Let’s say it’s the HTTP connector, but only a handful of people accessing these environments should be seeing and using this connector.
We have two options to handle this request:
1- Add the connector to the policy covering the existing environments.
This means everyone who can access the Business Area 1 environments has access to use the HTTP connector. This might be fine if you’re happy for everyone else to use it, but if not, you’ll need option 2:
2- Create a new environment, or cluster of environments.
Give these new environments their own DLP policy that includes the HTTP connector. No environments in Business Area 1 will be able to use the connector, but environments in Business Area 2 can. Security can be separated too, meaning only users with access to Business Area 1b will be able to use the HTTP connector. Some users can have access to both environment clusters if needed.
Even if the environments relate to the same business area, this additional segregation allows for more flexibility for connector usage.
Project specific
For some, this approach works well as part of a Power Platform environment strategy. Any high-value solution or set of solutions will have their own environment cluster. This also brings in other strategy concepts such as ringfencing data, security and/or connector usage.
Here, we might see multiple environments again. This time though, there might be more environments for extra layers of testing. This usually depends on the nature of the project & its value, be that political, commercial or something else.
We’d expect such high-value solutions to follow more stringent business practices. For example, treated as a critical line-of-business ‘system’ that needs to adhere to change management, design authority approval or other aspects.
It may be those processes that in themselves also dictate parts of your Power Platform environment strategy.
In the real world
For most organisations I work with, they’ve had plenty of historical environments and solutions to unpick and realign. They’re not working with a brand new, beautifully clean tenant. This makes things a little more complicated as there’s lots of unpicking to do.
1- The default environment has had years of activity. There’s lots of solutions housed here that could (and should) benefit from their own environments. Some may even look productionised and shared with a large audience. These would benefit from ALM and improved security.
2- There are already a lot of environments, created by previous admins. There looks to be a lot of duplication and solutions all over the place, which would benefit from a cleanup and realignment.
In reality, a Power Platform environment strategy will likely cover a mixture of the above concepts, and more. But rather than guess, starting with the data first can give you some good indications. Names of environments and solutions, or names of the creators will likely give clues as to where a strategy may start.
Getting started
We’ve previously talked about the importance of the CoE Starter Kit. This will pull all your Power Platform related data together, making it easier for you to review and make decisions. Environments are of course part of what’s covered in the kit.
Review existing environments
A place I’ll always recommend starting is using the Power Platform Admin View app to download an extract of your existing environments. A quick and dirty way is to export to Excel, then add some additional columns to track your review.
Firstly, identify any environments that can be deleted so you can clear the decks. You only want to work on your strategy with environments that are current and active. Work through those to identify themes, business areas or high-value solutions that might factor into your strategy.
It’s unlikely your strategy will be set in stone at this stage, but it will start giving you ideas.
TIP: Some environments will show as having a couple of apps. Don’t assume these environments are in use, as it may only be the system-default apps that are present:
Review apps in Default
Similarly, use the same app to export your Default environment inventory. Focus on apps shared with more users than you’d be happy with. Identify if any of these apps would fit into your strategy ideas from the environment review, or whether it dictates some alternatives.
Some of these apps might be small team productivity solutions, so a single, dedicated environment may suffice. Others may need a multi-environment approach.
Review connector usage
Yep, Power Platform Admin View app again. What connectors are being used in what environments? Are they in full use or under evaluation?
Example:
I worked with an organisation recently that had the following scenario:
1- Four separate environments.
2- Each had a decent volume of solutions.
3- Each had sprinklings of Power Automate Desktop usage.
The PAD usage was a mixture of test and genuine business value exploration.
We had to factor in licensing, data requirements and security, too. We determined a cluster of RPA-specific environments would be the best approach. This would:
1- Keep existing environments focused on non-PAD activity.
2- DLP for existing environments can remove access to the Desktop Flows connector.
3- Ringfence Power Automate Desktop activity to dedicated Managed Environments. These would have their own DLP policy.
4- Provide better base for evaluation and testing.
This involved a small amount of work, migrating solutions from the four environments into the new structure:
Review your ideation backlog
Another determining factor might be your pipeline of future work. You might be using the Innovation Backlog to track potential new opportunities for Power Platform solutions. Alternatively, you may be capturing them in another system or *cough* spreadsheet *cough*.
❓What data are we likely to capture for these❓
❓What connector(s) will we need❓
❓Who needs access❓
Do the answers align to anything in your proposed Power Platform environment strategy?
T-shirt sizing
T-shirt sizing has become more and more prominent in recent years. It’s mostly used as a project estimation tool for capacity planning, but can extend to other areas too (including the Power Platform). A solution for an individual or handful of people may be a size XS-S; a company-wide onboarding solution might need more support, ALM and governance so would be a L-XL.
These can also be determining factors when considering what environments you need.
Managed environments
If you’re not aware of Managed Environments yet, you can start reading about them here. The reality is, these are Microsoft’s direction of travel for additional governance and functionality. It’s best to understand their features (which will continue to grow), so you can understand where or how to weave Managed Environments into your strategy.
An easy method is, if all users in an environment cluster have premium (per user) licensing, may as well convert the environments to Managed. You’re always paying for the app-level premium functionality, so may as well make use of the environment-level too.
You can find the article about Power Platform environments, that Michael mentions, here.
Moving forward
With a decent schematic in mind, it’s a case of putting it into action. But your work as an admin doesn’t stop there. Here’s some things to consider for your new – and future environment strategy.
Communicate
Such an obvious one I know. In our previous article, we talked about the importance of a centralised area to communicate things with your makers. This includes your environment strategy!
Help makers to understand:
1- What they should be making and where.
2- How to request access to a specific environment or solution.
3- How to request a new environment and what the criteria is.
Automate environment creation
No Power Platform environment strategy will remain static for the length of time. It will need to evolve, be supplemented, grow.
Constantly creating and configuring environments could be tedious, so consider how you might manage this. The CoE Starter Kit has an environment request process which you could use to help. Note this uses Dataverse and, as this would be accessible by everyone, they’d all need a license.
You can also get under the hood with the automation and rebuild yourself. I know a lot of organisations do this so they can factor in their own criteria in the request form. You can also extend the automation logic yourselves too. For example, if you have a new project it will create x3 environments for you (DEV, UAT, PRD).
If you’re likely to only create environments on an adhoc basis, probably no need to worry.
Day-to-day management
Who is going to manage environments in your strategy? As a Power Platform admin you’ll be supporting the service, creating environments and security roles and all the other good stuff. But will you be doing all the administration for every environment?
For most organisations I’ve worked with, the answer is yes. There’s a fear of the wild west and so there needs to be a level of control. Cool.
The same organisations have hundreds, even thousands of SharePoint sites or Microsoft Teams in their tenant. Microsoft 365 admins will create them and support the service/platform, but others do the day-to-day. In SharePoint, some will have the Full Control privilege for a site. Teams have owners that can do more things than members.
Unfortunately, most of those with higher permissions aren’t trained properly. They don’t know how to manage permissions or keep things tidy. So, if you’re going to delegate day-to-day environment admin to others, keep that in mind.
Think bigger
An environment is just one cog in the wheel. It will invariably come with associated artefacts such as a DLP policy, security groups, group teams and more. Consider a solid naming convention so you can easily track and map these artefacts.
Example strategy
I recently worked with an organisation who needed some assistance with their Power Platform environment strategy. Over the course of a few months, we took their existing estate and provided some structure and governance for the short and long term.
Challenge
The organisation worked across multiple sites in the UK, but within a single tenant. We started by looking at the landscape and found:
250+ environments.
1 x DLP policy that was as useful as a fart in a spacesuit.
Anyone could create environments.
Default environment was pure carnage.
No real security or data strategy for environments.
Action
Using a combination of the concepts shared above, we moved to:
1- Delete over 200 unused environments.
2- Restrict creation of environments to specific admins only.
3- Review remaining environments, apps and connector usage to group activity into environments.
4- Create multiple DLP policies for each group of environments identified.
5- Provisioned new dedicated environments to best support current and future solutions.
6- All UAT and PRD environments were converted to Managed Environments, to make use of Power Platform Pipelines .
7- Update SharePoint hub with strategy & how to request access to newly created environment(s).
Result
The first huge result was defining standards. These would be applied to environment clusters for anything M-XL in solution size, underpinned with a consistent naming convention. The key different across the estate will be the left-three letters, used to determine each area, data type or project:
This structure repeats for around 10 different key areas, giving the bulk of their new environment structure. The area productivity environments kept XS-S solutions shared with only a handful of people that related to the Business/Data area but didn’t need full-fat ALM. It also keeps these use cases out of the Default environment.
As well as that, we needed to take care of other important aspects of their Power Platform environment strategy. The Power Platform admins had two environments covering the CoE Starter Kit & an environment for their own solutions. They had a fourth to evaluate preview features.
Meanwhile, dedicated sandbox environments were still needed to evaluate new connectors. These environments are temporary in nature (along with their associated DLP policy) until the evaluation is over.
Key decision
As a result of the initial environment clean up, we still had a handful that were active with solutions. How do we get solutions from these environments into the new structure?
We opted for the following approach to help drive the tidying up of the Power Platform estate:
Legacy: Any environments not formalised as part of the environment strategy are now legacy environments. Any support for these environments will relate to platform availability, licensing & data capacity only. Lower-level support for apps & flows will not be available until the solution is migrated.
Education: Work with makers to move their solutions into the relevant ‘team productivity’ or ‘dev’ environment. Full support will be available for solutions moved into the new structure. Increase awareness of creating solutions and where makers should be building.
Clean up: Decommission legacy environment(s) once emptied.
In closing
In the example above, the strategies and decisions were unique to a particular industry, with specific requirements. The truth is, no two environment strategies are likely to be the same. There’ll always be a quirk or a requirement that will determine what can or should happen. There’ll be common threads of course (such as a cluster of environments solely for Power Platform admins) but the rest is determined on a case-by-case basis.
Whilst it might seem daunting to have lots of environments, providing that structure is a key stepping stone for success. Bringing together environments, DLP & security form a strong tripod for every environment cluster you have. Take the time to think, analyse and craft a strategy that will work for your organisation.
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 are in one place, 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.
Another insightful article, Craig. Thankfully, the company I’m with now have just began the journey so starting on a clean slate. Just installed and configured the CoE, locked down the Default environment with DLP, and a strategy to organise Environments as we continue to grow etc. Definitely picked up some useful tips which I hope to incorporate. Thanks for sharing.