Dynamics 365 and the Power Platform are both deeply coupled with the Common Data Service (CDS).  Where CDS is the database behind both applications.  This is the second article of a series on PowerApps environments, where I focus on Dynamics 365 environments.

Where we left of last time…

In the first article of this series, Demystifying PowerApps Environments – Part 1 – The Default Environment,  I focused on the Default PowerApps environment.  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 her and Luke started learning about the Default PowerApps environment.  The diagram below depicts what has been set up in the tenant so far.

PowerApps Default environment with CDS
Default PowerApps Environment with internal and external data connectors.

Provisioning Dynamics 365

Sarah’s next step is to provision Dynamics 365 so that Luke can manage his customer’s service requests.  She provisions a Production instance then takes a look at what has been created.

First she starts with home.dynamics.com.  It looks like standard Dynamics 365 with all the Dynamics 365 apps in one place.

Dynamics 365 Home

Sarah then takes a look at her PowerApps home page and switches to the newly created Dynamics 365 Prod environment that has now appeared in the environments menu.  Lo and behold, all of the Dynamics 365 apps are sitting in her Recent apps list.  The penny has now dropped for Sarah, by provisioning a Dynamics 365 instance she has essentially provisioned another PowerApps environment with all of the standard PowerApps environment components (PowerApps, Microsoft Flow, Connectors and CDS).  The Dynamics 365 apps are just special Model-Driven PowerApps that have been developed by Microsoft.

Dynamics 365 PowerApps environment

Updating our diagram of the Dynamics Citizen Developer Inc. tenant we can see that we have two similar environments – one with the addition of a Dynamics 365 model-driven apps.

PowerApps Dynamics 365 Prod instance

Default Permissions In The Dynamics 365 Environment

Sarah is about to assign Luke the Customer Service Representative security role within Dynamics 365 so that he can start using it for his job.

However, seeing the similarities between the Dynamics 365 environment and the Default PowerApps environment, Sarah begins to wonder what permissions Luke will have in the Dynamics 365 environment.  Will he have the Environment Maker ability to create apps, connections, custom connectors, gateways, and flows in the Dynamics 365 environment too?

The Environment Maker role can create resources within an environment including apps, connections, custom connectors, gateways, and flows using Microsoft Flow. Environment Makers can also distribute the apps they build in an environment to other users in your organization. They can share the app with individual users, security groups, or all users in the organization

Microsoft Docs
Sarah opens the PowerApps Admin Center and navigates to the Security section of the Default PowerApps environment.  Clicking through to the Manage User Roles form, Sarah can see that Luke is not assigned the Environment Maker role by default.  However, we know from the previous article on the Default PowerApps environment that the Default Environment does not respect Environment Maker role as documented in the Microsoft documentation on the PowerApps predefined security roles.

Dynamics 365 Manage Security Roles

Sarah gets Luke to do a quick test.  He can’t see the Dynamics 365 environment on his PowerApps home page and therefore can’t create anything to do with PowerApps in there.  Great, that’s what we want!

Toggling The Environment Maker Security Role

Sarah now starts to get brave and decides to give Luke the Environment Maker role to see what the impact of turning it on is.

The result is that Luke can now see the Dynamics 365 environment on his PowerApps home page and has Environment Maker permissions in this environment.  He is able to create apps, connections, custom connectors, gateways, and flows in the Dynamics 365 environment.  Just as they would have expected.

However, when Sarah removes the Environment Maker role from Luke he is still able to see the Dynamics 365 environment on his PowerApps home page.  This is not expected. Luke then starts the process of creating a Canvas PowerApp within the Dynamics 365 environment. He gets all the way through creating the app and connecting it to Dynamics 365 as a data source.  It is only when he goes to save the app that he gets a permissions error and he is not able to save. This is a trick for new players, always save your PowerApp before you start configuring.  It’s possible to spend hours building a PowerApp only to have it not save because you do not have permissions.

A day later Luke opens up his PowerApps home page and finds that he no longer has access to the Dynamics 365 environment.  There is obviously some sort of delay with setting Environment Maker permissions in CDS and then those permissions propagating through to the corresponding PowerApps environments.

The Environment Maker role is the only thing that stops a user from creating PowerApps and Microsoft Flows that can access data in Dynamics 365.  With the array of connectors that allow PowerApps and Flow to connect to external data sources it is all too easy to accidentally share Dynamics 365 data with the outside world.  Imagine if Sarah, who has Global Administrator permissions, decided to go a bit crazy and started Tweeting Dynamics 365 data using PowerApps or Flow!!

Dynamics 365 Data to Twitter via PowerApps

Ensure That Your Dynamics 365 Data Is Secure

Similar to the Default Environment there are a number of things Sarah can do to stop users (and herself) creating PowerApps and Microsoft Flows in the Production Dynamics 365 environment which could have negative impacts on the business.

  1. 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.
  2. Set up Data loss prevention (DLP) policies to stop a PowerApp or Flow created in the Dynamics 365 environment from being able to share Dynamics 365 data externally.
  3. 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.

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:


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 2 – Dynamics 365 appeared first on Dynamics Citizen Developer.