Environments are containers that administrators can use to manage apps, flows, connections, and other assets; along with permissions to allow organization users to use the resources. The purpose of this article is to walk through important details about environments in the Power Platform and discuss recommended ways to benefit from proactively managing them.

Please read the environment overview documentation to get familiar with environments before developing an environment strategy.

Note: This is the first of an admin strategy series that we will be releasing over the course of the next few months, which is intended to provide guidance and recommended best practices on admin-related topics. Check back for updates and follow up posts on DLP, Layers of data security, ALM and more!

 

Figure 1: Example environment strategy diagram

Developing an environment strategy means configuring environments and other layers of data security in a way that support productive development in your organization, while securing and organizing resources. A strategy to manage environment provisioning, access and controlling resources within them is important to:

• Secure data
• Understand how to use the Default environment correctly
• Manage the correct number of environments to avoid sprawl and conserve capacity
• Facilitate proper Application Lifecycle Management
• Organize resources in logical partitions
• Support Operations (& Helpdesk) in identifying apps that are in production by having them in dedicated environments
• Ensure data is being stored and transmitted in acceptable geographic regions (for performance and compliance reasons)

 

Key take aways

Here is a starting point to consider for your environment strategy. 

1 Assign your admins the Dynamics 365 service admin role or Power Platform service admin role (available end of calendar year 2019)	2 Restrict the creation of net-new trial and production environments to admins	3 Treat the default environment as a ‘Personal productivity’ environment for your business groups
4 Establish a process for requesting access or creation of environments	5 Dev/Test/Production environments for specific business groups or application	6 Individual-use environments for POCs and trainings

 

 

Understand environments

Before we get started, let’s look at some environment and security key facts

• Environments are tied to a geographic location that is configured at the time the environment is created
• Environments can be used to target different audiences and/or for different purposes such as dev, test and production
• Data Loss Prevention (DLP) policies can be applied to individual environments or the tenant
• Every tenant has a Default environment
• Non-default environments can be created by licensed PowerApps, Flow and Dynamics users. Creation can be restricted to only global and service admins via a tenant setting
• Non-default environments offer more control around permissions
• An environment can have one or zero Common Data Service instances

 

Types of environments

Here is a summary of the different types of environments supported from a product standpoint with comments on intended purpose and security:

Type	Description and purpose	Security
Trial	Expires after 30 days, limit 1 per user. Can be used for short-term development, testing and personal exploration of the product. Provisioning trial environments can be restricted to admins.	Full control.
Developer	One per user, single access, community program https://aka.ms/powerappcommunityplan Developer environments cannot be shared with nor affect other users. They are not meant to be used as production environments for apps. Provisioning developer environments cannot be restricted unless through a support ticket.	Only single user account with community plan has access. Access cannot be shared
Default	Every tenant has one default environment. Mainly used for personal exploration and productivity, by extending Office 365 services. Default should not be used to host production apps. Create a DLP policy to limit data flow between trusted Microsoft connectors and 3rd party APIs in the default environment. You cannot block the automatic provisioning of the Default environment.	Limited control – all licensed users* are Environment Makers
Sandbox	Non-production environment enables some additional options like copy and reset. Used for development and testing, separated from production. Provisioning Sandbox environments can be restricted to admins (since production environment creation can be blocked), but conversion from production cannot be blocked.	Full control. Developers require Environment Maker access to create resources. If used for testing, only end user access is needed.
Production	Non-expiring full environment Used to host production solutions and internal POC/ training workshops. Requires 1GB of CDS database capacity to provision. Provisioning production environments can be restricted to admins	Full control. In production environments, restrict end-user access as much as possible, just enough use the application. Do not give anyone Maker access

*Users licensed for PowerApps, Flow, Office 365 and Dynamics 365 Online, stand-alone licenses, free and trial licenses.

 

Environment security

Different personas have different levels of access, and each are represented in two different ways depending on if the environment has CDS provisioned. If the environment has CDS, permission is controlled through the Security Role model (which is a table stored in CDS). If there’s no CDS, the permissions are Azure-based role assignments.

Persona	Details	Has CDS	Does not have CDS
Environment Admin	Can perform all administrative actions on an environment.	System Administrator (predefined) security role	Environment Admin role assignment
Environment Maker	Can create resources (e.g., apps and flows) in an environment but cannot make administrative actions on the environment itself. If CDS is provisioned, they can optionally be assigned maker access to the database.	Environment Maker (predefined) security role for Canvas and Flow. System Customizer (predefined) security role for Model/CDS customization.	Environment maker role assignment
End user	Can access assets like apps and flow buttons that are shared with them, but cannot create assets themselves. Note that end users are not given permission to the environment itself, they’re only shared access to the applications and database that are located in an environment.	Customized security role that provide access to assets in the environment (such as CDS and Model Driven apps). If using canvas apps, access is shared the same as non-CDS environments–at the app level.	Users are shared access to the canvas app (no environment role assigned)

Note on admin access: Global tenant admins, Dynamics 365 Service admins and Power Platform service admins can always view and perform administrative actions on any environment in the tenant from the admin center. Assign these roles in the Azure Portal using Privileged Identity Management (PIM).

 

Developing a strategy

Exploring the main goals in more detail:

• Assign your admins the Power Platform service admin or Dynamics 365 service admin role. These roles provide administrative access to PowerApps canvas apps, Flows, Model Driven apps, environments, custom connectors, connections, gateways, Power Portals, AI Builder models and all Common Data Service instances. This role should be assigned to admins that do not need global tenant admin access and are dedicated to managing Power Platform products.
  The new Power Platform service admin role will be available by the end of the calendar year 2019.
• Restrict the creation of net-new trial and production environments to admins
  Limiting environment creation is beneficial to maintain control in general: both to prevent unaccounted capacity consumption and to reduce the amount of environments to manage. If users have to request environments from central IT, it’s easier to see what people are working on if admins are the gatekeeper.
• Treat the default environment as a ‘Personal productivity’ environment for your business groups.
  Renaming the environment through the admin center is recommended to make the purpose of that environment self-explanatory. Clearly communicate that Default is never used for production apps, but for personal apps that aren’t meant to be used by many.
• Establish a process for requesting access or creation of environments
  With environment creation locked down and default reserved for specifically personal apps, make it clear to developers in your organization that a proper development project should be started by requesting a new dedicated environment where there’s clear communication of intent and support between developers and admins. In the next section there’s more detail about automated environment creation, which is just one way to implement an easy formal request process.
• Dev/Test/Production environments for specific business groups or application
  In a perfect scenario without constraints, each project or business unit should have their own set of development, test and production environments to develop solutions. Having staged environments ensures that changes during development does not break the end users in production and data is not corrupted. When resources are limited, focus this pattern for mission critical and important apps, or on business units who need their own dedicated space most.
• Individual-use environments for Proof Of Concepts and training workshops
  To host workshops, hackathons and internal training events like App in a Day or Flow in a Day, create a new separate environment for the event to keep everyone organized. Ask the users to save the resources they need in a short term after the event and clean up the environment, or reset it for other events.

The Default Environment

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. You can lock to this idea by adding a DLP policy that only allows data flow between trusted first party connectors.

 

Additional recommendations to manage environments

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

• Use a service account to deploy production solutions
  Create a service account that central IT manages to deploy to test and production environments. This is beneficial for many reasons:
  • • Allows all members of IT to manage admin resources (such as test and production environments) 
    • Only the service account has admin permissions in the environment 
    • All other users have end user permissions and cannot create new resources—This is important because if users are given access to a data connection, they cannot create any new interface to interact with the data that wasn’t intended by the developer 
    • IT is aware of production grade applications that are in deployment since they’re involved in the implementation
    • Service account will need Power Platform or Dynamics 365 service admin permission in PIM. Assign additional licenses as needed depending on what connectors need to be used in the request process (e.g., If Common Data Service and Outlook is used, assign premium PowerApps and Office Enterprise).
    • When displaying the details for an application it will show the service account as the creator and not the maker.  This will help end users know who to contact in case of application issues. 

  Consider if the risks of having a service account are important to you. Some organizations are not comfortable with having a service account for concerns such as: a shared resource with admin privileges cannot be tracked to a single person. This is valid, but can be mitigated with steps such as enforcing location based conditional access, tracking the audit logs to an IP, or more extensive methods like maintaining a secure access workstation that requires user identification during use and restricting the service account access to that device.

• Reduce the number of shared development environments
  Have separate environments for separate project development, especially when dealing with secure data. Environments are containers for resources such as connections to data, and in development environments there might be multiple people with Environment Maker access. If makers have access to a shared data connection and can create apps and flows, there is a risk that someone will create a new interface to read, update and delete data they might have been shared access to. This is especially important to keep in mind for the Default environment—you should always have important data connections, custom connectors, and other assets that need security in isolated environments to protect them. 
• Share resources with Azure AD Security Groups
  Security Groups can be used to manage access to PowerApps, Flows, Common Data Service security roles, and other Office 365 services such as SharePoint Online. This removes the admin’s burden to update access to individual end users for each component (especially if multiple are involved)—the app owners can modify that at the security group level without IT (unless IT restricts access to Security Group management). 
• Automate environment creation
  The admin connectors (Power Platform for Admins) makes it possible to create an approval flow where users request environments when IT has restricted environment creation to admins.  
  A request can be reviewed by central IT and approve or reject the creation of the environment, without having the responsibility to manually go to the admin center and create the environment for the user, just for validating the request details, business justification, DLP requirements, and if enough capacity is available.
• Create temporary development environments
  As mentioned, it’s recommended to separate development environments as much as possible, and specifically avoid simultaneous app development for critical solutions in the default environment. If environments are created for development purposes, put a deadline on how long the environment should be available to the developers and have a process in place to back up and remove them.
• Less is better
  Although it’s important to make sure resources are reasonably partitioned between projects and business units using environments, it’s still important to find a good balance between security and feasibility.  
  Managing shared test and production environments is a good way to facilitate a larger number of ‘Important’ solutions while preserving capacity and following best practices. This maintains restricted permissions because test and production have restricted environment permissions, and therefore the end users can’t modify the applications.
• Provision environments with CDS instances in the appropriate region 
  In companies where employees work in multiple countries, there might be some compliance considerations in terms of where data is stored and sent between countries. If the environment has a CDS instance, the data is physically being stored in the region. Review the list of supported environment regions.

 

Factors that influence provisioning

There are some factors that influence when to provision which types of environments:

1. Defined Tiers of application support
   The level of complexity, how critical the app is, and users impacted by the application (e.g., monthly active users / total users in org) are all important measures of how to provision environments to support all the scenarios.
   Organize different tiers of applications by:
   • Different types of applications should be separated in different environments based on how critical each is.

   

   Figure 2: An example of how to define types of application solutions and how they should be supported

2. Capacity
   Each environment (besides trial and developer environments) will consume 1GB to initially provision. This might be a constraint for provisioning environments if your organization does not pay for premium PowerApps or Dynamics licenses, and it’s also a shared capacity across the tenant needs to be allocated to those who need it.
   Conserve capacity by:
   • Managing shared test and production environments. Unlike shared development environments, permissions in test and production environments are limited to end user access for testing.
   • Automate cleanup of temporary development environments
3. Admin Involvement
   It’s not always possible to have the central IT involved in every development project happening throughout the tenant, especially if the IT team is smaller or there’s a larger enterprise to manage.
   Reduce the burden on the admin by:
   • Automating environment creation so the tenant admin only needs to approve the request.
   • Automate development environment cleanup with temporary environments

Hopefully this article is helpful for gaining a better understanding of the different Power Platform environment attributes, and provides useful recommendations on how to use them to your advantage.