Have you defined your Power Platform Environment strategy?

The Power Platform is Microsoft’s answer to the growing need in business for a way to build and customise low code professional-grade business solutions quickly, with the ability to connect to over 200 data sources including, SharePoint Online, Azure SQL, Twitter and more.

The concept of ‘Environments’ within the Microsoft Power Platform is often overlooked, however it should be one of the first items to review when deploying Power Apps and Power Automate. Unless you have been told or you have done your research, you wouldn’t know any different; your Power Apps and Flows are being created just perfectly fine.

What is a Power Platform Environment?

Environments are containers that administrators can use to manage data, apps, automations, connections, and other assets; along with permissions to allow users to use the resources.

Additionally, they:

• are tied to a geographic location that is configured at the time the environment is created
• can be used to target different audiences and/or for different purposes such as dev, test, and production (or by department/team)
• are containers that contain apps, flows, connections, and other assets; along with permissions to allow organisation users to use the resources
• manage Data Loss Prevention (DLP) policies, that can be applied to individual environments or the tenant
• can be created by licensed PowerApps, Power Automate users (this access can be restricted)
• can have one or zero Common Data Service (aka Dataflex Pro!) databases.

Developing a Strategy

Developing an environment strategy means configuring environments and other layers of data security (DLP) in a way that supports the use of the Power Platform in an organisation, while securing and governing resources.

Before defining a strategy its important that you know the types of environments that can be created.

Environment Type	Purpose
Developer	One per user; potentially licenced under the ‘Community Programme’ plan
Sandbox	Non-production environments. Enables the typical ‘Development’ and ‘Test’ environment isolation.
Production / Default	Personal productivity applications
Production / Dedicated	Non-expiring full environment. Dedicated to a single business application
Production / Shared	Non-expiring full environment. Dedicated to a single department.

Why is the Default environment special?

There is specific guidance for the Default environment to call out because of its unique nature:

• It’s automatically created with the first user in the region closest to the Azure AD tenant
• New users that sign up for PowerApps are automatically added to the Maker role
• Users are not automatically added to the Environment Admin role
• The default environment can’t be deleted, but you can rename it – e.g. Personal Productivity.

The Default environment should not be used to host production solutions. It’s designed to be an open environment that allows users to extend Office 365 and trusted applications or to build personal productivity applications that don’t affect many people.

Power Platform Environment Scenarios

To follow ‘proper’ application lifecycle management (ALM) principles, you need separate environments for development and production purposes. To provide some context to this, consider the following scenarios in your Environment planning:

• Scenario 1 – The ‘Out of the Box’, default environment.
• Scenario 2 – Scenario 1 + Dedicated departmental environments
• Scenario 3 – Scenario 2 + Dedicated application environments
• Scenario 4 – Multi-Tenant environment separation.

Scenario 1 – The Default Environment

Uses include: Personal Productivity Apps and Flows, Custom SharePoint Lists and Library forms.

Scenario 2 – Departmental Environments

Uses include: Default environment and dedicated department environments.

Scenario 3 – Departmental and Dedicated

Uses include: Default environment, dedicated department environments and a dedicated environment(s) for a single application.

Scenario 4 – Multi-Tenant Approach

Uses include: Separating Power Platform environments across physical tenants. Could be used to separate Production, Staging and Development environments, or could be used for geo-location reasons.

Recommendations / Best Practices

Based on successful experience with other customer engagements, below is a list of additional recommendations that can help make managing environments easier.

• Assign your admins the Power Platform service admin or Dynamics 365 service admin role.
• Restrict the creation of trial and production environments to admins
• Treat the default environment as a ‘Personal productivity’ environment
• Establish a process for requesting access or creation of environments
• Create separate Dev/Test/Production environments for specific business applications
• Individual-use environments for Proof of Concepts and training workshops
• Use a service account to deploy production solutions
• Reduce the number of shared development environments
• Share resources with Azure AD Security Groups
• Provision environments with CDS instances in the appropriate region
• Provision environments with CDS where you are expecting to make use of the Common Data Service; creation of an environment does not mean you have to create a Common Data Service database.