Connectors Reference

What a connector is

A connector is a proxy that wraps a service’s REST API behind a designer-friendly set of triggers and actions. You never call the API directly — you pick an operation, fill in typed inputs, and the platform handles the HTTP, auth token, paging and response shaping. There are 1,400+ connectors across Power Automate, Power Apps and Logic Apps, plus custom ones you build yourself.

• A trigger starts a flow (and most flows have exactly one). An action does work inside a run.
• A connection is separate from the flow — many flows can share one connection, and you rebind connections per environment via connection references.
• The same connector behaves slightly differently across products (Power Automate vs Power Apps vs Logic Apps); availability is shown on each connector’s reference page.

Connector tiers: standard, premium, custom

Every connector carries a tier that decides whether it needs a premium licence. The tier shows under the connector name in the picker (a *PREMIUM* badge) and on its reference page. This is the single most common source of "works for me, fails for them" surprises, because the licence is enforced per user who runs the flow, not just the maker.

• There is no "half premium" flow: a single premium operation makes the whole flow premium.
• The built-in operations (Control, Variables, Data Operations, Schedule/Recurrence, the *Request* trigger) are not connectors and carry no premium flag.
• Trigger or action — it does not matter: a premium trigger (e.g. SQL "When an item is created") makes the flow premium just as a premium action does.
• Browse the live tier lists on the connector reference: Standard · Premium.

Triggers: polling, webhook, instant & scheduled

A trigger is the entry point of a flow. Connectors expose triggers in a few flavours, and the flavour controls latency, cost and how the flow behaves when you switch it off and on again.

Polling vs webhook — the behaviour difference that catches people

Trigger tuning: conditions, concurrency & debatching

Trigger conditions

A trigger condition is a boolean expression evaluated before the flow starts. If it returns false the run is skipped — it does not even count as a started run. Use it to stop a flow firing on every change and filtering after the fact (which wastes runs and requests).

@equals(triggerOutputs()?['body/Status/Value'], 'Approved')

// Multiple conditions are ANDed. Reference trigger output with
// triggerBody() / triggerOutputs(), and use ?[ ] for safe navigation.

Trigger concurrency control

By default a trigger runs as many instances in parallel as its conditions allow. Turning on Concurrency control caps the degree of parallelism (1–100). Set it to 1 to force strictly sequential processing — useful to avoid *dirty reads* (acting on a record another run already changed).

Split On (debatching)

When a trigger returns an array, Split On debatches it — one flow run per array item — instead of looping inside a single run. The designer adds it automatically when the trigger’s schema is an array. It is great for fan-out, but it cannot be combined with a synchronous Response (the flow returns 202 Accepted immediately).

Actions: inputs, outputs & settings

An action performs one operation against the connector’s service inside a run. It takes typed inputs, returns a typed body you reference as dynamic content, and exposes per-action Settings that control retries, timeout, paging and security.

Reference an action’s output

body('Get_item')?['Title']
outputs('HTTP')?['statusCode']
first(body('List_rows')?['value'])?['name']

Connections, auth & connection references (ALM)

A connection is the credential the connector uses at runtime. Connectors authenticate in different ways — most Microsoft ones use OAuth (you sign in once), others take an API key, basic username/password, or a service principal. Connections are owned by a user (or an application user) and can be shared.

Connection references — the ALM piece

A connection reference is a solution component that sits between a flow and an actual connection. The flow binds to the *reference*; the reference is bound to a *connection* per environment. That indirection is what lets a solution move Dev → Test → Prod and be wired to the right credentials in each environment without editing the flow.

• Always build flows inside a solution so they use connection references, not hard-coded connections.
• Set connection-reference values per environment via deployment settings / pipeline variables, not by hand-editing in Prod.
• For unattended flows, bind the reference to a service principal (application user) connection so it does not break when a person leaves.
• See the Naming & ALM guide for the conventions and pipeline wiring.

Premium licensing: who needs what

Premium licensing is enforced at run time, per user. If a flow uses any premium / custom / on-premises connector, everyone who triggers or owns it needs an eligible licence — not only the person who built it. This is the classic reason a flow runs for the maker but fails when shared.

• Standard connectors are seeded with Microsoft 365 — no premium licence needed.
• Custom connectors and anything via the on-premises gateway always require a premium (or trial) licence.
• A Process licence dedicates capacity to one flow and exempts it from the activity-based shut-off — good for unattended/owned-by-service-principal flows.
• Multiple Process licences can be stacked on a single solution-aware flow; each adds 250,000 requests/day.

Power Platform request limits

A Power Platform request (PPR) is counted for every trigger and action a flow runs — connector actions, HTTP, and built-ins like Initialize variable or Compose. Both successful and failed actions count; skipped ones do not. Retries and extra requests from pagination count too. A simple one-trigger / one-action flow burns two requests per run.

• There is also a license-independent 5-minute ceiling of 100,000 requests — a Process flow can do 250k/day but never more than 100k in any 5 minutes.
• The window is per user / per flow and cannot be pooled across an environment or tenant.
• Stack Process licences on a solution-aware flow to add 250,000 requests each for genuinely high-volume automation.
• Desktop (PAD) flow executions do not consume Power Platform requests.
• Exceed the limit and your flows are slowed, not failed; sustained breaches for 14 days can turn a flow off.

Connector throttling & 429s

Connector throttling is different from the PPR allocation above. Each connector publishes its own rate limits (usually per connection, per time window) on its reference page, and these are frequently hit *before* the platform request limits. When you exceed one, the service replies 429 Too Many Requests with a Retry-After header.

• Leave the action’s Default retry policy on — it already honours Retry-After on 408/429/5xx.
• Cap Apply to each concurrency when the loop hits a rate-limited API; high parallelism multiplies your 429s.
• Spread work across more flows, or batch requests where the API supports it (e.g. Graph $batch, Dataverse batch) so one call does many.
• Cache lookups in a variable instead of re-calling the connector per row.
• Each connector’s exact numbers live on its page under the connector reference — always confirm there, they change.

Service limits cheat sheet

The hard ceilings on a single call, a single run, and a flow definition. These are platform limits — connectors may be stricter.

Custom connectors

When no connector covers an API, wrap it as a custom connector: describe the API with an OpenAPI (Swagger) 2.0 definition (or import a Postman collection), define auth, and the operations show up in the designer like any other connector. Custom connectors are premium — running any flow that uses one needs a premium or trial licence.

• Define the auth once (API key, OAuth 2.0, basic, or generic OAuth) — makers then just create a connection.
• Add policy templates to transform requests/responses (set a header, route, convert) without changing the backend.
• Build polling or webhook triggers so your API can start flows, not just receive actions.
• Package the custom connector in a solution with a connection reference so it deploys across environments via ALM.
• Submit for certification if you want it published to all tenants; otherwise it stays in your org.

DLP & governance

Admins control which connectors can be used together with Data Loss Prevention (DLP) policies. Every connector is sorted into one of three groups, and a flow may not combine a connector from the Business group with one from the Non-Business group in the same flow — that is how the platform stops, say, SharePoint data flowing to a personal Twitter/X connection.

• A flow that mixes a Business and a Non-Business connector is blocked from saving/running by the policy.
• The HTTP and custom connectors are common candidates to block or tightly scope, since they can reach arbitrary endpoints.
• DLP policies apply per environment (and tenant-wide default); Managed Environments add maker controls, sharing limits and analytics on top.
• Endpoint filtering can further restrict *which URLs/hosts* a connector may call.

Choosing & using connectors well

1. Pick the lowest tier that works. A standard connector avoids premium licensing for every runner — only go premium when the capability genuinely requires it.
2. Push, don’t poll. Prefer a webhook/push trigger over a polling one for latency and to avoid burning trigger requests on empty checks.
3. Filter early. Use trigger conditions and OData $filter/$select so you fetch the fewest rows and columns — fewer requests, less throttling.
4. Batch and cache. Replace per-row connector calls with a batched call or a cached lookup; each loop iteration is its own request.
5. Design for at-least-once. The platform can deliver a trigger more than once — make flows idempotent (check-before-create, Dataverse alternate keys).
6. Build in solutions with connection references so connectors deploy cleanly across environments — see Naming & ALM.
7. Know both limits. Watch the per-user PPR allocation *and* the per-connection throttle; the connector usually throttles first.