11.2 Evaluating and Recommending Connectors

A connector is a pre-built wrapper around a service's API. Power Platform offers more than 1,000 connectors, and every connector exposes triggers (events that start a run), actions (operations performed inside a run), or both. The Office 365 Outlook connector has both; the Approvals connector is actions-only — it can never start a flow by itself.

Standard, Premium, and Custom

• Standard connectors are included with Microsoft 365 licenses: SharePoint, OneDrive for Business, Office 365 Outlook, Office 365 Users, Teams, Excel Online. No Power Automate premium license is needed to use them.
• Premium connectors require a premium entitlement (Power Automate Premium, per-flow, or pay-as-you-go): Microsoft Dataverse, SQL Server, Salesforce, SAP, the generic HTTP actions, and all custom connectors. A flow containing even one premium connector is a premium flow, and every run-only user needs the matching license.
• Custom connectors wrap any REST API that is not already in the catalog. You build one from an OpenAPI (Swagger) definition, a Postman collection, or from blank — defining the host, authentication (none, Basic, API key, or OAuth 2.0, typically with Microsoft Entra ID), actions, and optionally webhook triggers. A custom connector is visible only inside the tenant where it is created or shared.

Exam trap: the HTTP actions are premium. A maker holding only a seeded Microsoft 365 license cannot 'get around' premium licensing by calling a third-party API with the raw HTTP connector instead of its premium connector.

Microsoft-Published vs Independent Publishers

Microsoft-published connectors ship from Microsoft and appear in every tenant. Independent publisher (verified) connectors come from ISVs and partners through Microsoft's connector certification program: the publisher submits the connector through the ISV certification pipeline, Microsoft validates its API definition, documentation, and security model, and once certified it is deployed to the public catalog for all tenants. Until a custom connector goes through certification it stays private to your organization — that lifecycle (custom → certified → public catalog) is a favorite exam point.

Connections vs Connection References

A connection is an authenticated instance of a connector stored in one environment — the result of signing in to SharePoint, SQL, or a third-party service. Connections live under make.powerautomate.com → Connections; they are environment-scoped and tied to the identity that created them.

A connection reference is a solution component that contains no credentials at all; it simply points at a connection. When a flow inside a solution uses connection references, application lifecycle management (ALM) becomes clean: export the managed solution, import it into production, and at import time point each connection reference at the production connection — no opening the flow, no re-authenticating inside the designer. This is why the exam's ALM questions push you toward always building flows inside solutions with connection references. Connections themselves cannot travel in a solution; connection references can.

DLP Policies: Business, Non-business, Blocked

Data loss prevention (DLP) policies are configured in the Power Platform admin center (Policies → Data policies) at tenant or environment scope. Every connector is classified into one of three groups:

Data cannot cross the Business/Non-business boundary inside a single flow or app. A maker who tries to save a flow combining Dataverse (Business) with X (Non-business) gets a DLP error at save time; if an admin later tightens a policy, already-enabled flows that violate it are suspended. Two nuances the exam likes: (1) certain Microsoft first-party connectors such as SharePoint and Teams cannot be blocked, and (2) DLP governs connector combinations — it does not inspect the data payload itself.

Throttling and Performance Limits

Each connector enforces its own throttling limits, and exceeding them produces HTTP 429 responses (Power Automate retries automatically, but throughput collapses). Numbers worth remembering:

• SharePoint connector: about 600 calls per minute per connection.
• Dataverse: service protection limits of roughly 6,000 requests per user per 5 minutes for paid licenses, enforced by the platform.
• Power Automate itself: per-license API request entitlements measured per 24 hours, plus structural limits such as the 100,000-item ceiling on an Apply to each loop.

Design around throttling: batch reads with OData filters and pagination instead of row-by-row loops, reuse trigger payload values instead of adding redundant Get row actions, and raise Apply-to-each concurrency only when the downstream connector can actually absorb the call rate.

Connector Action vs Dataverse Action: The Recommendation Trap

When the data lives in Dataverse, recommend the native Dataverse connector actions (Add a new row, Update a row, List rows, Delete a row, Relate rows, Perform a bound or unbound action) rather than generic HTTP calls against the Web API. The Dataverse connector handles authentication, OData query construction, and typed outputs for downstream dynamic content. The mirror-image trap is reaching for a custom connector when a certified connector already covers the service — build custom only when the API genuinely is not in the catalog. The decision order for any 'how should the flow call this system?' question is: native connector action → certified third-party connector → custom connector → raw HTTP as the last resort.