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.
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.
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.
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.
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.
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.
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
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.
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!
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!!
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.
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