Almanac

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.

feature-connection-references.mdv1 · history
CurrentApplies to Cloud flowsUpdated last monthSource Microsoft Learn

What it does

A connection reference is a solution component that points at a connection for a specific connector. Actions in a solution flow bind to the connection reference rather than to the connection itself, so the flow definition travels between environments unchanged while the credential behind it swaps out per environment.

Key facts

  • Flows use connection references for every connector. Canvas apps only use them for implicitly shared, non-OAuth connections such as SQL Server authentication.
  • A connection reference is created automatically when you create a connection from the flow designer, and Power Automate tries to reuse an existing one from the current or another solution before making a new one.
  • Flows added to a solution after being built outside one keep using direct connections. The flow checker surfaces a Use connection references warning with an action to strip the connections so references can be added. Exporting and reimporting in an unmanaged solution does the same conversion.
  • Whoever turns a flow on must own or have "Can use" rights on every connection behind its references. Otherwise you get ConnectionAuthorizationFailed.
  • Once the connection owner has turned the flow on, the flow holds explicit permission to use those connections and any co-owner can turn it off and on afterwards.
  • OAuth connections can only be explicitly shared with a user representing a service principal.
  • There's no limit on how many flows can share one connection reference, and no limit on actions per flow bound to one. Updates are applied asynchronously.
  • Connection reference ownership can't be transferred from the modern Solutions area. The classic solution explorer can change privileges.

When to use / skip

There's no skip here — if the flow is in a solution and you intend to deploy it, it needs connection references. The real decision is whose connections sit behind them. Use a service account or service principal from the start, because the alternative is a production process that stops working the day a consultant's account is deprovisioned. The only time you'd deliberately leave a maker's own connection in place is in a personal dev environment where nothing downstream depends on it.

Configuration decisions

  • Which identity owns each connection — named service account, service principal, or per-team accounts.
  • Whether connection references live in the same solution as the flows that use them, which they should, or in a shared solution.
  • Whether connections are pre-created in each target environment and referenced from a deployment settings file, or supplied interactively at import.
  • Your naming convention, since the generated names are useless at scale.
  • How custom connector connections are handled, given they must ship in a separate, earlier solution.

Gotchas

  • Custom connectors have to be imported in their own solution before the connection references and flows that use them. Ignore this and the import fails.
  • Copying an environment breaks connection references for custom connectors, because the identifier is environment-specific. You have to recreate the reference and fix everything using it.
  • A connection reference that already has no value in the solution or the target can't be updated during a pipeline deployment. Only ones with a previously deployed value can be changed.
  • A red exclamation mark on the flow details page means the underlying connection is in a bad state, not the reference. Fix or replace the connection.
  • Canvas apps don't recognise connection references on custom connectors at all. You have to edit the app post-import, which creates an unmanaged layer if the app is managed.

Consultant notes

  • Get the service account created before development starts. Connection ownership is the single most common cause of "it worked in test" on Power Platform projects.
  • Rename connection references as you create them. The default name appends the connector, solution name and a random suffix, and an environment with forty of those is unreadable.
  • Explain to the client that the connection reference decides which identity does the work. That's an access review conversation and it usually needs someone from security in the room.
  • Budget time for connection sharing in production. The mechanics are fiddly and the error messages are unhelpful.

Worth revisiting if connection reference ownership transfer ever lands in the modern solutions experience.

Was this accurate?