Your Guide to Environments in the Power Platform

Intro

Think of environments in the Power Platform as a way to create containers for your applications and data. These containers create boundaries that you can use to delineate purpose and secure data.

If you’re not familiar with environments at all, the first place you may experience them is in Power Automate or Power Apps. Take a look in the upper right corner and you’ll see an environment designation.  

You can click on this to select a different environment if you have multiple defined already.

First, let’s talk about what everyone starts with. Every organization has a default environment. Any time a user is added to the organization they are added to the default environment. Default environment will always have Dataverse and you might think of this as your default Dataverse. If you do nothing else, the default environment is where all of your users will build Power Automate Flows and Canvas Apps. For example, if a user starts using Approvals in Teams, all of the approval data will exist in Dataverse in the default environment. This behavior makes the default environment a good place for personal automation.  

Your default environment is where everybody in your organization is going to create things to start. So all their “stuff” is going to be contained in that environment by default. And until you need experimental work or customization of the environment in some way, this is probably ok.

Next, let’s talk about some reasons for creating separate or dedicated environments.

Extending Dataverse

Any time you’re looking at Dataverse (CDS) as a place to store data for your application and you have the need to customize or extend the data model, you should consider creating a new Dataverse instance for your application. The reality is if you end up customizing entities or creating new entities within your default Dataverse, things can get muddy pretty quickly. The more apps you add to your environment, the more customization, which could mean more conflict.

Dynamics Applications

Microsoft Dynamics instances are a good example of applications that require separate environments. Dynamics relies heavily on Dataverse entities and whenever you decide to use Dynamics it will force you into provisioning a separate environment with Dataverse. In a way, you might say Dynamics is a super example of Dataverse extension.

Power Platform Management Add-Ins like PPCoE

Another example is the PPCoE solution provided by Microsoft. This solution is intended to give high-level oversight and governance capabilities across all Power Platform resources in your organization. This solution also requires a separate environment and Dataverse. Even while deployed in a separate container, the PPCoE provides cross-environment reporting and control, demonstrating the ability for integration between multiple environments.

Another side effect of having a separate environment for something like the PPCoE is the built-in ability to secure it appropriately. The PPCoE must allow admins to retrieve statistics from all Power Platform resources in addition to providing control and approval processes when basic users ask to create new Power Platform resources (Flows, Canvas Apps, etc.).

It should also be noted that having a Dataverse is not required in an environment. The examples we’ve talked about already all rely on Dataverse. But you’re free to have environments that do not have Dataverse. If you were building applications that strictly used SharePoint list data or SQL Server, you wouldn’t need a Dataverse.

Application-Specific Purpose - DEV, TEST, PROD

One thing we don’t want to forget is the ability to use Power Platform environments as containers dedicated to the application development lifecycle. To put it simply, if you’re building a business application on the Power Platform, it probably makes sense to have environments dedicated to DEV, TEST, and PRODUCTION for that business application. Of course, this gives your team a safe place to build and make changes, a controlled place to validate features, and a reliable application for end-users. When using environments in this way, you can take advantage of mechanisms like “solutions” and “environment variables” which help to create app lifecycle capability and provide a mature and quality model for deployment in the Power Platform.

Large Orgs

Another special circumstance where it makes sense to think about using environments would be in large organizations where there is a need for separation of data or concerns based on the agency lines within the organization. Examples of this might be large hospital systems where it’s important to secure PHI data according to different rules, or State governments where many agencies are having separate and distinct roles or purposes and the need for each to have some autonomy in control over their environment.

Pro-Tip: In case you were wondering

I’ll offer one additional pro-tip that may keep you from searching endlessly for an answer. At the moment, “direct” or “tight” Office365 integration only works with the default environment. What does this mean? Specifically, when you create form customization, using Power Apps, for a SharePoint List or Library, these can only be created in the default environment. Additionally, using the “For a selected item” and “For a selected document” triggers in Power Automate will only add the Power Automate menu trigger to the List or Library if your flow is created in the default environment.