Dynamics 365 and the Power Platform are both deeply coupled with the Common Data Service (CDS) and are held in containers called environments.  There are different types of PowerApps environments and each environment type has its quirks.  This is the third article of a series on PowerApps environments, focusing on the Production PowerApps environment.

Where we left of last time…

The first and second articles of this series focused on the Default environment and Dynamics 365 environments.  Part 1 set the scene with an overview of PowerApps and Dynamics 365 environments.  I introduced a fictitious company, Dynamics Citizen Developer Inc., and a couple of personas, Sarah and Luke.

Dynamics 365 Admin
Sarah, IT Manager, Global Admin rights across Office 365 tenant
Dynamics 365 End User
 Luke, Customer Service Rep, Office 365 and Dynamics 365 licenses

As the IT Manager, Sarah, has been setting up the Office 365 tenant and environments for Dynamics Citizen Developer Inc.  Sarah has got as far as provisioning Office 365 and Dynamics 365.  The diagram below depicts what has been set up in the tenant so far.

PowerApps Environments in Tenant
PowerApps environments set up in the Dynamics Citizen Developer Inc. tenant.

Provisioning a Production Environment

Sarah’s has decided that she would like to have a separate environment to hold their production PowerApps. Her next step is to provision a Production PowerApps environment.  This is done through the PowerApps Admin Center.

New Powerapps Environment

When creating the environment, Sarah is prompted to create a database using the Common Data Service (CDS).  At this stage, Sarah decides that the environment only needs to hold Canvas PowerApps since she already has a CDS database as part of the Dynamics 365 environment.  She skips the database creation.

Powerapps Environment Create without Common Data Service

The PowerApps Production environment without CDS is created.

Powerapps Environment without a Common Data Service Database

Environment Security Is Different Without CDS

Luke has become quite proficient at creating Canvas PowerApps.  Sarah would like to add Luke as an Environment Maker to the new production PowerApps environment so that he can build PowerApps for the company.  Sarah opens the Security tab of the environment in the PowerApps Admin Center. “Well, this is different…” she thinks when looking at Security tab. It is nothing like the Security tab that we saw for the Dynamics 365 environment in Demystifying PowerApps Environments – Part 2 – Dynamics 365.

Security tab for PowerApps environment without a CDS database
Security tab for a PowerApps environment without a CDS database
Security tab for PowerApps environment with a CDS database
Security tab for PowerApps environment with a CDS database

Clicking on the Environment Maker role in the new Production PowerApp environment, Sarah is able to add Luke as an Environment Maker without going through the more convoluted process she had to for the Dynamics 365 environment in Demystifying PowerApps Environments – Part 2 – Dynamics 365.

Add Environment Maker to PowerApps Environment without CDS
Add as user to the Environment Maker role for a PowerApps environment without CDS

Environment Security With CDS

Sarah decides that a CDS database is required for the Production PowerApps environment to store data for one of the Canvas apps that Luke is building.  She adds the CDS database and then checks the Security tab of the environment.  It has changed!

security tab change when cds database added
Security tab changes when a CDS database is added.

The reason for this is that the Environment Maker and Environment Admin role settings are actually contained within the CDS database itself.  CDS uses the Dynamics 365 Security Roles functionality that it has inherited from Dynamics 365.  When the CDS database is added to the PowerApps environment it is also enabling the Dynamics 365 user interface (Model-Driven PowerApps) and the security is then managed via that interface.

Sarah clicks on Assign Security Roles to check Luke’s permissions and he still has his Environment Maker role.  She also notices that the Environment Admin role has changed slightly to be called System Administrator.

Manage PowerApps Security Roles in CDS

Governing the Production PowerApps Environment

Similar to the Dynamics 365 environment there are a number of things Sarah can do to govern the Production PowerApps environment.

  1. Use the Environment Maker and Environment Admin (System Administrator in CDS) to manage who can create PowerApps components and administer the environments.
  2. Use the Admin and Maker connectors to create PowerApps and Microsoft Flows for monitoring and enforcing the company’s policies.  For example, use the Connector Browser tool to inspect which connections are being used.
  3. Set up Data loss prevention (DLP) policies to stop a PowerApp or Flow created in the Production environment from sharing sensitive internal data externally.
  4. Monitor the Analytics area of the Power Platform Admin Center to see app usage.  If there are PowerApps that no-one is using, maybe they can be removed.

The Updated Tenant

Updating our diagram of the Dynamics Citizen Developer Inc. tenant we can see that Sarah has now created three similar environments – all with their different behaviours!

Tenant with three PowerApps Environments

Other Articles in this Series

Each of the other environment types behave differently.  Take a look at the other articles in this series for more details:

References

If you want to find out more about PowerApps environments, here are some useful links.

PowerApps Environments Overview

Administer environments in PowerApps

PowerApps and Microsoft Flow Governance and Deployment Whitepaper

Persona Avatars designed by Freepik from Flaticon

The post Demystifying PowerApps Environments – Part 3 – Production Environments appeared first on Dynamics Citizen Developer.