9.3 Standard Connectors, Custom Connectors & Connection References

Standard Connectors, Custom Connectors & Connection References

Connectors are the fundamental architectural bridges that enable Microsoft Power Platform applications and flows to communicate with external services, databases, cloud platforms, and on-premises systems. Operating as declarative wrappers around RESTful APIs, connectors translate underlying HTTP endpoints, OpenAPI specifications, and JSON schemas into user-friendly triggers and actions. For the PL-200: Microsoft Power Platform Functional Consultant exam, you must understand connector tier classifications, author and secure Custom Connectors, and implement Connection References to ensure healthy, enterprise-grade Application Lifecycle Management (ALM).

---

1. Power Platform Connector Architecture & Tiers

A Connector is a proxy wrapper around a RESTful web service that exposes the service's API endpoints as structured Triggers and Actions in Power Automate and Power Apps.

+-----------------------------------------------------------------------------+
|                     POWER PLATFORM CONNECTOR ARCHITECTURE                   |
|                                                                             |
|   +-------------------+       +--------------------+                        |
|   | POWER AUTOMATE /  | ----> |     CONNECTOR      |                        |
|   |    POWER APPS     |       |   (OpenAPI Proxy)  |                        |
|   +-------------------+       +--------------------+                        |
|                                         |                                   |
|                     +-------------------+-------------------+               |
|                     |                                       |               |
|                     v                                       v               |
|           +--------------------+                  +--------------------+    |
|           | STANDARD CONNECTORS|                  | PREMIUM CONNECTORS |    |
|           | - Office 365 / M365|                  | - Dataverse        |    |
|           | - SharePoint Online|                  | - SQL Server       |    |
|           | - OneDrive / Teams |                  | - Salesforce / SAP |    |
|           | - Forms / Planner  |                  | - HTTP / Webhooks  |    |
|           | - Included in seed |                  | - Premium license  |    |
|           +--------------------+                  +--------------------+    |
|                                                             |               |
|                                                             v               |
|                                                   +--------------------+    |
|                                                   | CUSTOM CONNECTORS  |    |
|                                                   | - Proprietary APIs |    |
|                                                   | - OpenAPI / Postman|    |
|                                                   | - Premium license  |    |
|                                                   +--------------------+    |
+-----------------------------------------------------------------------------+

Connector Classification Tiers

[!IMPORTANT] The HTTP Connector Rule for PL-200: Adding a generic HTTP or HTTP with Microsoft Entra ID action to any flow immediately elevates the entire flow to Premium, even if all other triggers and actions use Standard connectors (like SharePoint or Outlook). Organizations cannot bypass Premium licensing by calling external APIs via raw HTTP actions without standalone licenses.

Data Loss Prevention (DLP) Connector Categorization

Power Platform Administrators govern connector usage across environments using Data Loss Prevention (DLP) policies, grouping connectors into three compliance buckets:

1. Business (Confidential): Connectors permitted to share business data (e.g., Dataverse, SharePoint, ERP).
2. Non-Business (No Business Data Allowed): Personal and consumer connectors (e.g., Twitter/X, Facebook, Gmail).
3. Blocked: Connectors completely prohibited from running in the environment.

Rule: Connectors in the Business group cannot share data with connectors in the Non-Business group within the same flow or app.

---

2. Custom Connectors Architecture & Development

When prebuilt connectors do not exist for an internal microservice, proprietary ERP, or niche SaaS platform, functional consultants and developers author a Custom Connector.

+-----------------------------------------------------------------------------+
|                     CUSTOM CONNECTOR AUTHORING METHODS                      |
|                                                                             |
|   [1. OPENAPI SPECIFICATION]       ---> Import Swagger 2.0 or OpenAPI 3.0   |
|                                         (JSON or YAML definition file)      |
|                                                                             |
|   [2. POSTMAN COLLECTION]          ---> Import Postman Collection (v1 / v2) |
|                                         with preconfigured request samples  |
|                                                                             |
|   [3. MAKER PORTAL WIZARD]         ---> Define Host, Base URL, Endpoints,   |
|                                         and JSON Request/Response schemas   |
|                                                                             |
|   [4. AZURE SERVICE EXPORT]        ---> Direct 1-click export from Azure    |
|                                         API Management or Azure App Service |
+-----------------------------------------------------------------------------+

Custom Connector Authentication Types

When provisioning a Custom Connector, you must select one of four security authentication protocols:

+-----------------------------------------------------------------------------+
|                   CUSTOM CONNECTOR AUTHENTICATION SCHEMES                   |
|                                                                             |
|   [NO AUTHENTICATION]        ---> Public endpoints, open weather/stock APIs |
|                                                                             |
|   [BASIC AUTHENTICATION]     ---> Username & Password (Base64 encoded)      |
|                                                                             |
|   [API KEY]                  ---> Static token passed in Header, Query,     |
|                                   or Custom Header (e.g., X-API-Key)        |
|                                                                             |
|   [OAUTH 2.0]                ---> Enterprise Identity Providers:           |
|                                   - Microsoft Entra ID (Azure AD)           |
|                                   - Google, GitHub, Salesforce, Generic     |
|                                   - Authorization Code Grant                |
|                                   - Client Credentials Grant                |
+-----------------------------------------------------------------------------+

Configuring OAuth 2.0 with Microsoft Entra ID

Integrating an internal REST API secured by Microsoft Entra ID requires standard OAuth 2.0 handshake configuration:

1. Identity Provider: Select Azure Active Directory.
2. Client ID & Client Secret: Generated during App Registration in Microsoft Entra admin center.
3. Login URL: Default is https://login.microsoftonline.com.
4. Tenant ID: common (multi-tenant) or specific Tenant GUID (single-tenant).
5. Resource URL: The Application ID URI of the backend API (e.g., api://contoso-inventory-service).
6. Redirect URL: Automatically generated by Power Automate after saving the connector (e.g., https://global.consent.azure-apim.net/redirect). Must be copied and pasted into the Entra ID App Registration's Redirect URIs.

Policy Templates (No-Code Request/Response Transformation)

Policy Templates allow makers to modify outbound HTTP requests and inbound responses without writing custom middleware code:

• Set HTTP header: Injects static or dynamic headers (e.g., injecting an authorization token or tenant identifier).
• Set query parameter: Appends mandatory URL query string parameters.
• Route request: Redirects requests dynamically to different base paths or hosting servers.
• Set property / Convert array to object: Modifies JSON payload structures on the fly to match flow requirements.

---

3. Connection References & Enterprise ALM

In early Power Platform architectures, cloud flows stored hardcoded connection references pointing directly to individual user connection instances (/connections/shared_sharepointonline/a1b2c3...). This created severe Application Lifecycle Management (ALM) failures:

• Exporting a solution from Dev and importing into Test/Prod failed because the developer's personal connection did not exist in target environments.
• Flows were imported in a disabled state, requiring administrators to manually open every flow and re-authenticate each connection.
• Breached security compliance by embedding developer identities in production assets.

+-----------------------------------------------------------------------------+
|                  CONNECTION REFERENCE ALM ARCHITECTURE                      |
|                                                                             |
|   [DEVELOPMENT ENVIRONMENT]                                                 |
|   +---------------------------------------------------------------------+   |
|   | FLOW DEFINITION: References 'cr123_SharePoint_ConnRef' (Proxy)      |   |
|   |                                  |                                  |   |
|   |                                  v                                  |   |
|   | CONNECTION REFERENCE: Points to -> [Dev User Connection]            |   |
|   +---------------------------------------------------------------------+   |
|                                     |                                       |
|                                     v (Export Solution as Managed)          |
|   +---------------------------------------------------------------------+   |
|   | SOLUTION ZIP: Contains Flow JSON + Connection Reference Metadata    |   |
|   | (NO HARDCODED PERSONAL CREDENTIALS OR CONNECTION GUIDS!)            |   |
|   +---------------------------------------------------------------------+   |
|                                     |                                       |
|                                     v (Import Solution into Production)     |
|   [PRODUCTION ENVIRONMENT]                                                  |
|   +---------------------------------------------------------------------+   |
|   | FLOW DEFINITION: Unchanged! References 'cr123_SharePoint_ConnRef'   |   |
|   |                                  |                                  |   |
|   |                                  v                                  |   |
|   | CONNECTION REFERENCE: Bound to  -> [Production Service Principal /   |   |
|   |                                     Service Account Connection]     |   |
|   +---------------------------------------------------------------------+   |
+-----------------------------------------------------------------------------+

How Connection References Function

A Connection Reference is a Dataverse solution component (connectionreference) that acts as an abstraction proxy between a cloud flow action and the actual physical connection in the environment:

1. Solution Component: Connection references reside natively inside solutions with a publisher prefix (e.g., cr123_shared_dataverse_89abc).
2. Flow Decoupling: Inside the flow JSON definition, actions call the Connection Reference Logical Name rather than a hardcoded connection GUID.
3. Target Binding: During solution deployment to Test or Production, automated deployment pipelines (or the solution import wizard) prompt administrators to map the Connection Reference to an existing connection in the target environment—such as a dedicated Service Principal connection.

Deployment Automation with deploymentSettings.json

In enterprise DevOps pipelines (using Azure DevOps Power Platform Build Tools, GitHub Actions, or Power Platform CLI pac), connection references are bound automatically without manual intervention using a deployment settings configuration file:

{
  "ConnectionReferences": [
    {
      "LogicalName": "cr123_shared_sharepointonline_45a67",
      "ConnectionId": "prod-sharepoint-service-account-guid",
      "ConnectorId": "/providers/Microsoft.PowerApps/apis/shared_sharepointonline"
    },
    {
      "LogicalName": "cr123_shared_dataverse_89b01",
      "ConnectionId": "prod-service-principal-connection-guid",
      "ConnectorId": "/providers/Microsoft.PowerApps/apis/shared_commondataserviceforapps"
    }
  ],
  "EnvironmentVariables": [
    {
      "SchemaName": "cr123_SharePointSiteUrl",
      "Value": "https://contoso.sharepoint.com/sites/ProductionOperations"
    }
  ]
}

Command-line execution via Power Platform CLI:

pac solution import --path MySolution_managed.zip --settings-file deploymentSettings.json --activate-plugins

[!TIP] ALM Best Practice (PL-200 Exam): Always create Connection References inside a solution before creating cloud flows. When adding actions in the modern flow designer, ensure the action uses the solution Connection Reference rather than an ad-hoc personal connection. This ensures flows remain 100% solution-aware and deploy cleanly via automated CI/CD pipelines.