• Home
  • About Us
  • Contact Us
  • Privacy Policy
  • Special Offers
Business Intelligence Info
  • Business Intelligence
    • BI News and Info
    • Big Data
    • Mobile and Cloud
    • Self-Service BI
  • CRM
    • CRM News and Info
    • InfusionSoft
    • Microsoft Dynamics CRM
    • NetSuite
    • OnContact
    • Salesforce
    • Workbooks
  • Data Mining
    • Pentaho
    • Sisense
    • Tableau
    • TIBCO Spotfire
  • Data Warehousing
    • DWH News and Info
    • IBM DB2
    • Microsoft SQL Server
    • Oracle
    • Teradata
  • Predictive Analytics
    • FICO
    • KNIME
    • Mathematica
    • Matlab
    • Minitab
    • RapidMiner
    • Revolution
    • SAP
    • SAS/SPSS
  • Humor

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

May 2, 2020   Microsoft Dynamics CRM

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]

5672.pastedimage1588280124582v1 Monitoring the Power Platform: Connectors, Connections and Data Loss Prevention Policies

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.

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

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.

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

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.

2538.pastedimage1588280124584v4 Monitoring the Power Platform: Connectors, Connections and Data Loss Prevention Policies

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.

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

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.

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

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

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

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.

1207.pastedimage1588280124586v8 Monitoring the Power Platform: Connectors, Connections and Data Loss Prevention Policies

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.

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.

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

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.

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

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.

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

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 <cmdlet name> -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.

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

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.

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

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

PowerShell.Get AdminDLPPolicy.NonBusinessGroup Monitoring the Power Platform: Connectors, Connections and Data Loss Prevention Policies

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

Let’s block ads! (Why?)

Dynamics 365 Customer Engagement in the Field

Connections, connectors, data, Loss, monitoring, Platform, policies, Power, Prevention
  • Recent Posts

    • Siemens and IBM extend alliance to IoT for manufacturing
    • Kevin Hart Joins John Hamburg For New Netflix Comedy Film Titled ‘Me Time’
    • Who is Monitoring your Microsoft Dynamics 365 Apps?
    • how to draw a circle using disks, the radii of the disks are 1, while the radius of the circle is √2 + √6
    • Tips on using Advanced Find in Microsoft Dynamics 365
  • Categories

  • Archives

    • February 2021
    • January 2021
    • December 2020
    • November 2020
    • October 2020
    • September 2020
    • August 2020
    • July 2020
    • June 2020
    • May 2020
    • April 2020
    • March 2020
    • February 2020
    • January 2020
    • December 2019
    • November 2019
    • October 2019
    • September 2019
    • August 2019
    • July 2019
    • June 2019
    • May 2019
    • April 2019
    • March 2019
    • February 2019
    • January 2019
    • December 2018
    • November 2018
    • October 2018
    • September 2018
    • August 2018
    • July 2018
    • June 2018
    • May 2018
    • April 2018
    • March 2018
    • February 2018
    • January 2018
    • December 2017
    • November 2017
    • October 2017
    • September 2017
    • August 2017
    • July 2017
    • June 2017
    • May 2017
    • April 2017
    • March 2017
    • February 2017
    • January 2017
    • December 2016
    • November 2016
    • October 2016
    • September 2016
    • August 2016
    • July 2016
    • June 2016
    • May 2016
    • April 2016
    • March 2016
    • February 2016
    • January 2016
    • December 2015
    • November 2015
    • October 2015
    • September 2015
    • August 2015
    • July 2015
    • June 2015
    • May 2015
    • April 2015
    • March 2015
    • February 2015
    • January 2015
    • December 2014
    • November 2014
© 2021 Business Intelligence Info
Power BI Training | G Com Solutions Limited