Are you worried about Office 365 sprawl? We'll help you learn about environments in the Power Platform.
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.
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.
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.
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.