5 FAQ: Environments & The Power Platform

I recently spoke to a new client about Power Automate, and as I ran through the list of considerations --licensing, self-service purchasing, administration-- I realized that I hadn't provided enough information about environments to really help drive their understanding.  Here was a client that already had a process in place for developing new solutions and responsive tiered help desk support, but they were awash in questions and concerns about how to balance support for creative business users with IT best practices.  Today I want to answer some common questions about environments to bring everyone up to speed.

What is an environment?

At its very basic, an environment is a container for developing and testing in the Power Platform.  Flows, apps, solutions, etc. are environment-specific, though they can be exported from one environment and imported into another so they can be shared with additional users as they move from development to production.  CDS databases are also environment-specific, which helps to separate test data from production data.

Environments in the Power Platform add an important level to the development life cycle, bringing low-code/no-code solutions created by makers and citizen developers into the IT fold in a comfortable and sustainable way.  Along with DLP Policies and administration practices, properly used environments provide a sandbox for development and creativity while maintaining the integrity of production-ready solutions.  

Which environment am I in?

Every tenant comes with a "default" environment.  Everyone has access to the default environment, but other environments can be created for one or more users, effectively creating "development" and "UAT" environments as needed.  Users can only enter environments to which they have been granted access.

The environment for the current logged in user is indicated in the suite bar:

To switch environments, click the current environment name and choose another from the list:

Who can create new environments?

This is actually a tricky question because, by default, a user's license determines whether or not he or she can create an environment.  Before the panic sets in (!!), note that the majority of Office 365 licensed tenant users will not qualify for this.  Only Global (Tenant) administrators and CDS Service administrators can create environments regardless of license, and these folks can restrict environment creation to specific users.  This can be done either in the Power Platform Admin Center or via PowerShell.  For more information about licenses that do allow environment creation, review the current documentation.

How do I create new environments?

To create a new environment, go to the Power Platform Admin Center.  On the left rail, click Environments, then click New.

A pane will appear on the right with a form for the new environment.

There are some other things to consider, such as what type of environment this will be and whether or not a CDS database is required. We won't go into those here, but one major caveat is that every environment--with or without a database-- requires 1GB of available capacity.  To check your current capacity, visit the Capacity page in the Power Platform Admin Center.

OK, I buy it...How Many Environments Do I Need?

Well, it depends.  Since all users have access to the default environment, that's really not the best place to develop and test enterprise critical applications.  Best practices suggest that the default environment is really for personal automation and applications appropriate for small team use.  Examples of these are:

• A flow that notifies me when an email arrives in a shared inbox
• A Power App and associated flow for managing vacation requests/approvals within a small team

If capacity isn't a concern, creating 3 dedicated environments provides the most stable experience for your enterprise applications.  This means 1 development environment, 1 UAT environment, and 1 production environment.  Applications move from development to production in a straight line, and requested changes/updates are made in development, tested by users in UAT, and then deployed to production.  

This will feel very familiar to developers and testers who have been involved in traditional application development.  If this article helped and you're interested in more, you can find additional information on governance and best practices in the updated Power Apps and Power Automate Admin whitepaper.




Photo by CHU TAI on Unsplash