Almanac
Microsoft/power-automatePower Platform

Consultant KB for Microsoft Power Automate end to end: cloud flows, desktop flows and RPA, connectors and integration, AI and agent flows, process and task mining, approvals and human-in-the-loop, ALM and solutions, governance and security, licensing and capacity, monitoring and troubleshooting, plus cross-cutting decision guides. Implementation notes, configuration decisions and the gotchas that bite on real projects. Populated by the daily author agent from the Power Automate release plans, docs repo and product blog, plus the author's own consultant notes.

power-automate/03-connectors-and-integration/feature-connection-authentication-and-oauth.md
feature-connection-authentication-and-oauth.mdv1 · history
CurrentApplies to Cloud flowsUpdated last monthSource Microsoft Learn ↗

What it does

A connection is the stored credential that lets a flow act against a service. It's created by a person, owned by that person, and shared between Power Automate and Power Apps — create one in either service and it shows up in the other. Most connectors use OAuth, so the connection holds a refresh token rather than a password.

Key facts

  • Connections live under Data > Connections in the maker portal. Deleting one removes it from both Power Automate and Power Apps; updating credentials updates it in both.
  • A broken connection shows a Fix connection link, and the flow fails until someone re-authenticates it.
  • You can see which flows and apps depend on a connection from its Details pane — worth checking before deleting anything.
  • Some connectors, SharePoint among them, offer Connect using on-premises data gateway as an alternative connection path to the same service.
  • Connections are shareable for some auth types and not for others. Where a connection isn't shareable, each user of a shared app or flow has to create their own.
  • The HTTP with Microsoft Entra ID (preauthorized) connector needs a Global Administrator to create OAuth2 permission grants for the scopes it uses. Microsoft ships a PowerShell script for this because the Azure portal can't do it. Consent changes take up to an hour to reach pre-existing connections; new connections pick them up straight away.
  • Signing into Power Automate with one account and trying to connect to SharePoint or Microsoft 365 with a different one fails in tenants with matching-account policies.

When to use / skip

Connection ownership is the design decision people skip and regret. Use a named user's connection for personal productivity flows where the flow acting as that person is the point. Use a dedicated service account for anything business-critical, anything shared, and anything whose failure would be noticed — because a named user's connection dies with their leaver process, and the flow dies with it. Where the connector supports it, a service principal connection is cleaner still, since there's no interactive credential to expire.

Configuration decisions

  • Named user versus service account versus service principal for each connector in the solution.
  • Whether connection references are used so connections aren't baked into the flow definition and can be re-pointed per environment.
  • Who owns the service account, where its credentials sit, and whether it's excluded from the MFA and password-rotation policies that would break it — or, better, configured so those policies don't apply.
  • Which connectors DLP policy allows to sit in the same policy group, since that's evaluated across all connections in a flow.
  • Whether admin consent is needed up front for OAuth connectors, and who in the client's tenant can grant it.

Gotchas

  • OAuth refresh tokens expire on conditional access policy changes, password resets and long periods of inactivity. The flow doesn't warn you — it just starts failing, and the run history says the connection is invalid.
  • Connections are owned by individuals even when the flow is co-owned. A co-owner can edit the flow but can't fix someone else's connection.
  • The leaver process is the biggest single cause of production flow failure. When the account is disabled, every flow using its connections stops, usually at the worst possible moment.
  • Sharing a flow doesn't share the connection. The other person sees the flow, opens it, and gets prompted to supply their own credentials for a connector they may not be licensed for.
  • Connections created outside solutions don't move between environments. The flow deploys and then sits broken until someone points it at a valid connection by hand.

Consultant notes

  • Get the service account provisioned in week one. It always takes longer than expected, needs a licence, and needs an exemption discussion with the security team.
  • Make connection references mandatory for solution-aware flows. It's the difference between a deployment being a click and being an afternoon.
  • Warn the client that connections are an operational asset needing an owner and a monitoring story. "Flow stopped working" is nearly always "connection expired", and someone needs to be watching for it.

Recheck when the client changes conditional access or password policy — that's usually when the connections start falling over

Was this accurate?
Related
Connection references07-alm-and-solutionsService principals and application users08-governance-and-securityCustom connectors03-connectors-and-integrationFlow sharing and ownership08-governance-and-securityPremium connector licensing09-licensing-and-capacityTenant isolation08-governance-and-security