Monitoring the Power Platform: Connectors, Connections and Data Loss Prevention Policies (2023)

Summary

Connectors are used throughout Power Platform Pillars such as Microsoft Power Automate and Microsoft Power Apps. They are also used in Azure services such as Azure Logic Apps. Connectors are a wrapper around first and third party APIs to provide a way for services to talk to each other. They represent the glue between services, allowing users to setup Connections to connect various accounts together. These connectors encompass a wide range of SaaS providers including Dynamics 365, Office 365, Dropbox, Salesforce and more.

This article will explore Connectors and Connections to help administrators better understand how they are being leveraged within the Power Platform. We will discuss components of connectors and where to go to find out about connectors used with Power Apps and Power Automate. Next, we will connections and their boundaries and impact. Finally, we will explore Data Loss Prevention Policies and how to restrict connector usage for business and non-business related purposes.

Connector Components

Each connector used in the Power Platform consists of operations called "Actions" and "Triggers".

Actions

Actions are operations that read, change or manipulate data or variables, all directed by a Maker. These are tied to the Connector (Open API) definition provided by each service. Examples include Reading data from the Common Data Service, sending emails through Outlook or internal operations such as parsing JSON or looping through a result set.

Triggers

Triggers represent notifications to Microsoft Power Automate Flows or Azure Logic Apps that an event has occurred. They are generally grouped into two types of triggers: Poll and Push Triggers.

A polling trigger makes a call into the API at a reoccurring frequency to check for new messages. When new data is available, the trigger will run the Flow or Logic App. Examples include timer triggers. A great breakdown into explaining, using and creating a custom connector that uses polling is titled "Use a polling trigger for Azure Logic Apps and Microsoft Power Automate".

[NOTE: CLICK ON EACH IMAGE FOR INCREASED CLARITY]

A push trigger is a listener waiting for an event to occur or a message to be received. Once received, the trigger will run the Flow or Logic App. Examples include Flow button presses, HTTP or Webhook connectors. Another article, titled "Use a webhook as a trigger for Azure Logic Apps and Power Automate", explains how to create a custom connector for GitHub to listen for push events on a repo.

Connector Definition

In the case of the Dropbox connector, we can see in the documentation the actions and triggers defined in the Open API definition. This same definition is available using the PowerApps Administration PowerShell module or Management connector and the list connectors action. The image below was extracted from the Management connector list connector action.

Each connector definition will include a "tier" property, this tells administrators if the connector is considered premium. This can also impact out DLP Policies discussed below.

Standard and Premium Connector Tiers

Both Standard and Premium tiers are available based on the type of Office 365 licensing. Below you'll find references to both tiers. Standard licenses, where the service is owned by Microsoft, can't be added to the Blocked Data Loss Prevention Policy discussed below.

List of Premium Connectors

List of Standard Connectors

Preview and Production Connector Release Statuses

Preview Connectors, can be used in Production environments but with caution as indicated by the light blub symbol attached to each connector. If a connector is not in preview, then its considered in a Production release status. For each connector, check to see the regional availability using the links provided.

List of Preview Connectors

List of Production Connectors

Custom Connectors

As described above, hundreds (as of this time 325+) of connectors exist to allow Power Apps and Power Automate to talk to services. That said, there will eventually come a time where an API that your app or flow needs to talk to will not be available as a provided connector. Luckily, the concept of Custom Connectors can help fill this gap.

Custom connectors allow developers to build and secure APIs that can be consumed by Makers and Users of the Power Platform. Common examples include using Azure Functions or Web Apps to build an API and using Azure AD to secure the API. Finally, the API will need to be defined and described using a specification called Open API. One of the advantages of using Azure Functions is that it can generate the Open API spec for a developer, allowing for a seamless handoff to the author of the Custom Connector.

This image from the Custom Connectors overview does a wonderful job of visualizing the steps involved here.

The scope of creating a custom connector covers a wide range of additional concepts and considerations, such as authentication and access protocols. I would consider starting with this step by step to begin creating your own Custom Connector or here for using the Logic Apps Custom Connector service in Microsoft Azure. Custom connectors are scoped to a specific environment, this is important when discussing Data Loss Prevention Policies below.

Solution Aware Connectors

Custom connectors can also be created within Dynamics 365 or Common Data Service solutions. Enterprises that need to utilize custom connectors in a production ready environment, will want automation tools to migrate changes from developers. Solution aware custom connectors, as part of a Common Data Service solution, can be neatly packaged and moved across sandbox and test environments towards production. Administrators can leverage existing tools such as Solution Packager to unpack and store within source control.

When working with custom connectors in solutions, be sure to reference and evaluate the Known Limitations currently with this feature.

Connections

Connections are used by Power Apps and Power Automate to activate and work with Connectors. When viewing within the Portal, each connection has an identifier, the connector its using, the creation time and who created it as well as the current environment and status. Each connection shows how its used across Power Apps and Power Automate Flows. The below image shows a connection in the Maker Portal.

Here is the same Azure Application Insights connection shown using the PowerShell module for Power Apps Administration tasks. This option provides us an option to view the current status programmatically.

The same connector can be used for multiple connections as shown in the image below with multiple entries for Azure DevOps.

Connections can be connected to a user account but can also work with service principals. The supported types of authentication are None, Basic, API Key and OAuth 2.0.

Connections across environments

Environments represent boundaries between data sources, customizations, etc within the Power Platform and this includes connections. One question that will eventually come up is how to work with solution aware components that use connections. The connections that may be used for development purposes won't necessarily work in production workloads.

The typical approach I've seen is to create the connections manually and update the connector's connection where needed. Using PowerShell or potentially other connectors (i.e. Power Automate Management), automation techniques can be applied as part of your ALM strategy.

Quick Point on Migrating Managed Solution Power Automate Flows

Recently I begin investigating scenarios of moving flows and applying connections as referenced above. Using that approach I was able to apply connections using automation techniques with Microsoft Power Automate. This worked and I was able to successfully apply the connection and turn on the Flow using the Power Automate (CDS) API. However by doing this, an active unmanaged layer was introduced. This causes concern as subsequent changes performed on the flow will be underneath the active layer as pointed out in this Known Limitations section.

"Importing a solution containing a flow will not automatically create or associate required connections. The flow must be edited to fix the connections.

• If using managed solutions, this creates an active customization in the unmanaged layer. Therefore subsequent solution updates to the flow will not be reflected."

Until I find a solution to this, consider removing the active layer and applying the solution. In my findings when the active layer was applied, the flow reverted back to its original state. Here is the extracted flow to use as an example.

Data Loss Prevention Policies

Data Loss Prevention Policies help protect and secure organizational data within an enterprise by providing rules enforcing what connectors can be used. Connectors can be grouped into Business, Non-Business and Blocked classifications which determine if they can be used within Power Apps or Flows. These policies can be scoped to a specific environment or across all environments within a tenant.

Here is an image showing a Business Data Only policy I created that is scoped to a single environment.

Blocked policies restrict resources from interacting with a specific service. All third-party connections and Microsoft owned Premium connectors (except Common Data Service) can be blocked.

This image shows an error message when attempting to use connectors that are from different policy groups.

DLP Policies and Power App Administration PowerShell

As detailed in "Introducing HTTP and Custom Connector Support for Data Loss Prevention Policies" by Jonathon Levesque, these policies can be used for HTTP and Custom Connectors. There is an important note that Jonathon documents that is worth pointing out:

"To add support for custom connectors and/or HTTP connectors to a policy using the PowerShell, download and import the latest PowerApps PowerShell scripts from the link above and use the cmdlets ‘New-AdminDlpPolicy’, ‘Set-AdminDlpPolicy’, ‘Add-CustomConnectorToPolicy’, and ‘Remove-CustomConnectorFromPolicy’ to modify a policy. The cmdlet ‘Get-Help -detailed’ can be used as a reference.

Note: Use the schema version ‘2018-11-01′ when creating or updating a DLP policy to include HTTP connectors. Adding HTTP support using the template or PowerShell will only affect the specified policy. New policies created via the Admin Center will not contain the HTTP connectors.

Caution: WE DO NOT SUPPORT DOWNGRADING FROM SCHEMA VERSION 2018-11-01. Once HTTP support is added to a policy, it cannot be taken away. Attempting to do so may corrupt that DLP policy. Furthermore, if a DLP policy is updated to support HTTP connectors, current flows using these HTTP capabilities may be shut off."

This image shows, using the Power App Administration PowerShell module and the Get-AdminDlpPolicy cmdlet, I can list out the connectors for both business and non-business groups.

Using the below PowerShell command, the DLP Policy can be read and audited.

Get-AdminDlpPolicy {DLP Policy Name}

The PowerShell command above shows how to work with the DLP Policy Name to limit the response to a specific policy. The name can easily be found in the URL within the PowerApps Admin Portal.

Here is a gif showing the login flow and using the Get-AdminDlpPolicy and reviewing the Non-Business Data Group.

Next Steps

In this article we have covered foundational information and concepts for Connectors, Connections and Data Loss Prevention Policies. We have discussed some of the boundaries and limitations to be aware of. Examples of working with the Power Apps Admin Portal as well as the PowerApps Administration PowerShell modules were examined.

This article is a good starting point to better understanding how to work with powerful connectors such as the Power Automate Management and Admin connectors referenced in a future article. The article also begins the journey into the Power Automate API and how solution layers can impact changes to components.

If you are interested in learning more about specialized guidance and training for monitoring or other areas of the Power Platform, which includes a monitoring workshop, please contact your Technical Account Manager or Microsoft representative for further details.

Your feedback is extremely valuable so please leave a comment below and I'll be happy to help where I can! Also, if you find any inconsistencies, omissions or have suggestions, please go here to submit a new issue.

Index

Monitoring the Power Platform: Introduction and Index