Work or School Accounts Now Enabled in Community!
On May 12 Work or School Accounts were enabled in Community, along with Microsoft accounts (MSA). This allows seamless navigation between Community, Dynamics 365 applications, and Azure Active Directory enabled sites while logged into your Work or School account.
Read more | Managing Accounts
Dynamics 365 2019 release wave 2 plan Discover the latest updates to Dynamics 365.Release Plan | Weekly Deployment Notes
Ace your Dynamics 365 deployment with packaged services delivered by expert consultants.Explore service offerings
Connect with the ISV success team on the latest roadmap, developer tool for AppSource certification, and ISV community engagements.
ISV self-service portal
The FastTrack program is designed to help you accelerate your Dynamics 365 deployment with confidence.
FastTrack Program | Finance and Operations TechTalks | Customer Engagement TechTalks | Talent TechTalks
I am always learning about the Power Platform, Dynamics 365 and the crossover they have with the Common Data Service (CDS). Whenever I think I have a good handle on it, I realise that I don’t. It has taken me a couple of months to find all the information for this article. I have read blogs, posted on forums and experimented in my own Power Platform and Dynamics 365 environments. However, it wasn’t until I attended a Microsoft PowerApps course that it all came to light. Now, I think, I have all the answers I need to write something intelligent.
This is part one of a series of articles that aim to demystify the sometimes confusing world of PowerApps, Dynamics 365 and CDS environments. Part one focuses on the Default PowerApps environment.
I am going to talk about two categories of environments in this series of articles. I will refer to them as Dynamics 365 instances and PowerApps environments.
A Dynamics 365 instance can be a Production or Sandbox Dynamics 365 organization which has its own database. Find out more here. This article refers to instances that are on version 9.x of Dynamics 365, where the underlying database is the CDS. This is important to note.
A PowerApps environment is essentially a container for PowerApps, Microsoft Flow, a CDS database, gateways and connections. These containers can be used to separate Production, Test and Development environments, for example, but also have other uses and attributes which can be read more about here.
I will start this journey by introducing a fake company and a couple of personas. This will enable us to talk about how different user roles within a company interact with the environments.
Dynamics Citizen Developer Inc. is a brand new company and has decided to go with Microsoft cloud offerings for all of their software needs. As part of this they will be implementing Office 365 and Dynamics 365 as their core application set.
Sarah is an IT Manager and is tasked with setting up and managing all of the Microsoft cloud services. She is responsible for making sure that everything operates smoothly on the IT front and has Global Admin rights across their Office 365 tenant.
Luke is a Customer Service Representative and also works for Dynamics Citizen Developer Inc. He’s tech savvy and at his previous company he liked to explore all the apps available to him through his Office 365 and Dynamics 365 licenses so that he could be more effective at his job. He will not be given a PowerApps plan license.
Office 365 is the platform on which Office 365, the Power Platform and Dynamics 365 resides. Every organisation’s Office 365 platform sits under an Azure AD tenant and only the users within that tenant (usually the organization’s staff) can access the applications.
Sarah provisions Office 365 in their Dynamics Citizen Developer Inc. tenant. Included is a PowerApps environment by default. Unsurprisingly, this is called the “Default” environment. The Default environment is provisioned with PowerApps and Microsoft Flow automatically. This is depicted in the following digram. The diagram which will grow as Sarah and Luke interact with the environments.
When Sarah navigates to PowerApps through the Office 365 portal she sees the default environment already set up. It has her company\tenant name with (default) appended to it.
Default PowerApps environments are very special. I will explain below
Every user, within the company’s the tenant, that has a PowerApps license can access the Default environment.
Luke, being tech savvy and explorative, finds this out quickly. Through his Office 365 and Dynamics 365 licenses, which include PowerApps, he is able to execute the following actions in the Default environment:
Sarah finds out that Luke is able to carry out all of the actions above and she decides to investigate. She’s puzzled because she hasn’t given Luke permissions to any PowerApps environments.
Sarah opens the PowerApps Admin Center and navigates to the Security section of the Default PowerApps environment. Under the environment roles, she opens the Environment Maker role and notices that a user named Tenant is a member of this role. This means that everyone in the Tenant, including Luke, has Environment Maker role permissions to the Default PowerApps environment.
When Sarah tries to remove the Tenant user from the Environment Maker role she is presented with an error and is unable to do so.
Things are now starting to make a bit more sense. Sarah knows from the Microsoft documentation that the Environment Maker role is giving Luke the access that he is experiencing.
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
With Luke and his colleagues having free reign over this environment things could become unmanageable in a short period of time. Imagine the mess, multiple PowerApps and Microsoft Flows accessing multiple data sources, inside and outside of the tenant. With no governance to restrict what users can do, you can see where data and security quickly become at risk.
There are a number of things Sarah can do.
Before the Microsoft Business Application October 2018 update, Sarah noticed that the Default environment did not have a CDS database. When she tried to create a CDS database she recieved an error.
However, Sarah has been able to create a CDS database in the Default environment since the October 2018 update, so clearly things have changed!
Sarah is now worried. Luke currently has a lot of free range to create and edit PowerApps, Microsoft Flows and Connectors in the Default environment. Now there is a CDS database, does that mean he can start modifying the CDS data model and creating Model Driven apps? Luckily the answer to this is no. There is an extra layer of security at the database level which means that Luke cannot modify the data model or create a Model Driven app unless he is given access.
This article has focused on the Default PowerApps environment which has special characteristics that are not obvious at first glance. Office 365 Administrators need to be very aware of these characteristics and put plans in place to make sure they don’t end up with an unmanagable environment with potential security holes. Microsoft have provided the tools to do this, administrators just need to decide how to apply them.
Other environment types behave differently to the Default environment. Look out for more articles following this one on the other types of PowerApps and Dynamics 365 environments.
If you want to find out more about PowerApps environments, here are some userful links.
PowerApps Environments Overview
Administer environments in PowerApps
PowerApps and Microsoft Flow Governance and Deployment Whitepaper
Business Applications communities