As the Power Platform has grown big last past years, there has been a flooding of users building business productivity and personal productivity apps. This is certainly a good sign for the adoption of the concept of ‘Citizen Developers’ as envisioned by Microsoft when they first introduced the Power Platform concept. However, this has led to a strong need for governance inside organizations, who are pacing their digital transformation on the Power Platform. My intention with this article is give some high level practical pointers which organizations can leverage to manage the chaos when it comes to security, data access, monitoring and support for business applications built by their employees on the Power Platform.

1. Managing User Access 

Internal User Access

Power Platform have notion of environment to as where things happens – user make Power Apps, Power Automate flows or create a CDS / Dynamics 365 installation. Power Platform admin center is the default admin center for managing all environments that contains power automate, Power Apps and common data service databases. This is place you can see the all environments your organizations have which users or groups have access to these environments as shown in image below.

Note: There are two distinct Admin centers for Power Apps and Power Platform. The later one is in preview mode still and there is a certain degree of overlap between the two in terms of  functionalities. However certain actions for e.g. Environment security and data policies can be only be accessed and configured from the Power App admin center. For most of the scenarios discussed and screenshots used in this article, I have used the Power App admin center. As per Microsoft official documentation Power Platform admin center is still in preview mode and more functionalities will be added to it.

Default Environment: all the users in the office 365 tenant with a proper Power App license has access to the default environment. The default environment does not have a CDS DB out of the box but it can be provisioned. It is not possible to delete this environment. This is an excellent place for in house employees to start creating personal productivity assets as they discover personal business needs or in their work area that can help them to build automation in their work area and help perform better day to day operations.

• Environment Maker : Users under this role are allowed to make assets in an Power Platform Environment: Power Apps, Power Automate flows, Custom Connectors, Connections etc.
  They also have the possibility to distribute the apps they build in an environment to other users in their organization.
• Environment Admin: This role provides users rights to perform administrative actions in an environment: add or remove a user from either the Environment Admin or Environment Maker role,create a CDS database, view and manage all resources and create data loss prevention policies.

Note: Once a CDS database is created in an environment, then we see a different way of controlling security in that environment for the users. You get a URL for the environment (similar to Dynamics 365 security management portal). The below example shows where a Power App/ Power Platform environment is converted to a CDS environment(with a Dynamics 365 App) and the security roles are converted and managed by Dynamics 365 security management UI.

External Users Access

• External users from another Office 365 tenant: For this feature to work Azure B2B access should be turned on and the guest users should have a valid Power Platform license, either from the current organization or from their own external Office 365 tenant. This makes it possible to share Power Apps and flows to external users from any other Office 365 tenant. This works perfectly for scenarios where a company is collaborating for business processes with suppliers or partners. It helps to more streamline the business process across organizations by making it easier for external users work in business process automation and access data in and out of the main organization. However, the guest users need to have been added as a guest in individual application(s) that the Power Platform assets connects to, for this to work in practice.

• External users on CDS portals: In scenarios where external customers or partners working within the scope of a business process application built on Power Platform as an CDS application, an intuitive way is to setup portals on CDS and engage external actors to proactively contribute and engage on business applications. You can read about this in a detailed post made by me earlier here.

2. Managing Data Security 

When we talk about data security we talk about two distinct areas:

• Data Connections: This refers to the ability to connect to data sources in different applications (Microsoft 365 and 3rd party), while developing Power Platform assets: Power Apps, Power Automate etc.
• Data Visibility: This refers to what data is visible inside Power Platform CDS applications and other Office 365 applications that your Power Platform assets connect to.

Data Access Control by DLP policies 

The data policy defines what data sources the assets (Power Apps, Power Automate flows, custom connectors etc) can connect to in an environment. In simple words what data movement is allowed between organizations IT ecosystem (Microsoft 365) from 3^rd party services (Instagram, Twitter, SAP etc) and vice versa.

Lets talk about the options that can be configured for data policies and later I present a use case how these settings can be applied in a real life scenario for Power Platform implementation.

Steps to create a DLP Policy

1. Navigate to Data Policy section under Power Apps admin center and click on create ‘New Policy’.

2. On clicking on ‘Environments’ you will see the data policies can be defined and applied in effect at three configurations when comes to scope of environments as shown below.

When one of these configurations is chosen with an environment(s), in the next step we configure connection restrictions to data sources by defining data groups.

3. Next select ‘Data Groups’. This defines a logical way of grouping of connectors to various data sources. By default, the names of the two groups are as business data and non business data, but they are merely a way to make two groups of connectors which can be used in only in exclusivity. What it means in practicality is that a connector added in Group A (business data only ) cannot be used with a connector in Group B (non business data)
in an environment where the data policy is applied to. My personal option is that we could see more categories in data groups to add connectors to in near future.
But as of today it is limited to two groups only. By default all data connectors are under ‘Non Business’ data group.

4. To add data connectors to ‘Business Data’ group, click on the ‘+’ Add icon. Next it will popup a search window, where you can search different relevant connectors that you would like to add to the ‘Business Data’ only group.

5. After you added the required connectors they appear under the ‘Business Data’ group as shown in image below.

How Environments and Data groups works in combination ?

To be able to understand and design the right data policies for your Power Apps / Power Platform environments, lets consider a scenario as depicted in the image below.

• Global Policy #1 : Start with a global policy for your organization which is highly restrictive i.e. all the Microsoft 365 products connectors are put under ‘Business Data’ group (Group A) and all 3rd party connectors external to Microsoft 365 ecosystem such as Twitter, SAP, LinkedIn are put under ‘Non Business Data’ group (Group B).

• Policy #2: Define a policy for your internal organization users who can be using Power Platform for making their own business productivity apps or trying out some experiments or learning the Power Platform. In this policy group the most connectors for Office 365 products that is used by your business under ‘Business Data’ group (Group A). The remaining connectors of Microsoft 365 products such as Dynamics 365 / CDS / Azure AI and 3rd party connectors is grouped under ‘Non Business Data’ group (Group B). This makes sure that the business users are only assets that connects to products in Office 365 , that they use in accomplishing their daily workday task.

 In case some business users who are more advanced and want to also try new features of Power Platform such as AI Builder, which in turn depends on CDS connectors, these users can be given access to a separate training environment (different from the default environment) with a CDS DB and appropriate extra data connectors can be added to this environment’s DLP policy under ‘Business Data’ group. The default environment does not have a CDS database and it is recommended not to create one in the default environment.

• Policy #3: This kind of policy can be used for more open and Pro IT development project scenarios. Consider there is a need for a department developing a business application using Power Platform assets, which need to connect to data sources from outside Microsoft 365 ecosystem, there could be made and exception policy for that specific environment. An example of such application can be a Power Automate flow that connects to Twitter handle of company and read tweets and creates incidents or cases for customer service department in Dynamics 365 Customer Service CDS application. This scenario involves connectors for Dynamics 365 / CDS, Twitter and other Office 365 products such as Exchange / SharePoint.

Data Visibility Control in Microsoft 365 Applications

• Data visibility in CDS applications: Here we see a list security roles from Dynamics 365 security management portal that govern the data visibility of the data  that the CDS / Dynamics 365 connectors connect to, as shown in images below.

For e.g. a user trying to make a Power App that connects to a CDS / Dynamics 365 DB but not have any CDS security roles to access data from CDS, will not be able to do CRUD actions on CDS data.

• Data Visibility in other Microsoft 365 applications: The data visibility that a user connects to using connectors to Microsoft 365 applications suite, depend on security defined for user or user groups at the level of those individual applications. An example can users trying to use a Power App data connector to a SharePoint document library where they by default don’t have implicit read action privilege, will not be able to read data even if the environment’s DLP policy allows to use SharePoint connector.

I highly recommend to read these below listed white papers (PDF links) from Microsoft released earlier this year for a very deep dive into the Power Platform governance.

• Administering a PowerApps Enterprise Deployment
• Power Platform Governance and Administration

If you are keen to know how to better govern your organizations Power Apps / Power Platform environments or need help to build an internal Power Platform governance strategy for your organization, please don’t hesitate to contact me at sumit.sah@soprasteria.com / +4746726207.