Although they live in separate parts of Power Automate, it's important to know the distinction between a connection and a connection reference.
It's worth understanding how they work and what the advantages are since, in certain cases, you can only use one of them.
Let's take a look.
Connector, connection, connection reference
Three words, three different things, and the distinction is the whole article.
A connector is the wrapper around a service. Microsoft describes it as "a proxy or a wrapper around an API that allows the underlying service to talk to Microsoft Power Automate, Microsoft Power Apps, and Azure Logic Apps." The SharePoint connector is one, the Outlook connector is another. It's the catalog of triggers and actions you pick from.
A connection is "a stored authentication credential for a connector", for example the OAuth credentials for the SharePoint connector. It's a specific account, already signed in, with whatever permissions that account happens to have. Connections belong to a person and live in one environment, so you can have multiple connections to different places, even outside the Microsoft ecosystem, a Gmail account for example.
A connection reference is "a solution component that contains a reference to a connection about a specific connector." Emphasis on the "solution" part, since it's a named placeholder that lives inside the solution and points at a connection.
If I may oversimplify, a connection is a phone number, and a connection reference is the entry in your contacts that says "Plumber". Your flow only ever dials "Plumber". It never learns the number, and it doesn't need to. Get a new plumber and you edit that one contact, and every call placed through it lands somewhere new without you rewriting anything that dials it.
Let's check what it's for.
Connection references are great
With a connection reference in between, the binding is to the reference itself and not to the connection. So if you have complex flows with hundreds of actions that use the same connection, and you need to export and import them into another environment, you only need to change it in one place.
The flow definition never changes between environments, only what the reference points at. The contact name travels, the number behind it gets filled in locally.
The second benefit shows up during ordinary maintenance. To change which account a solution flow uses, you edit the connection reference component inside the solution. You don't open the flow, you don't touch the actions, and on a managed solution you don't create an unmanaged layer on top of a flow you never meant to customize.
One edit updates every action pointing at that reference, and there's no limit on how many flows or actions can share one. You change the number behind the "Plumber" contact and that's it.
Which one your flow is using
The dividing line is the solution. Flows created outside a solution use connections directly. Flows created in a solution use connection references, and the reference points at the connection.
That line isn't quite as clean as it sounds, though, and this is the part worth holding on to. Legacy flows can sit inside a solution and still be using plain connections. Microsoft is explicit that canvas apps and flows added from outside solutions will not automatically be upgraded to use connection references, so dragging an existing flow into a solution changes where it lives without changing how it binds. If you need to make that conversion, here's how to convert them.
Common mistakes
The flow won't turn on after an import
Cause: you get a ConnectionAuthorizationFailed error, which means the user trying to activate the flow doesn't have permissions to at least one of the connections the flow uses.
Solution: either the person who owns all the connections turns the flow on, or they share every connection with the person who will, using the "Can use" permission. Once the flow has been turned on by the owner of the connections, the flow itself has explicit permission to use them and co-owners can toggle it off and on freely. One catch worth remembering: OAuth connections can only be explicitly shared with a user representing a service principal.
A red exclamation point sits on the connection reference
Cause: the connection reference shows as "invalid" on the flow details page, which means the underlying connection is in a bad state rather than anything being wrong with the reference itself.
Solution: go to the connection behind the reference and update it, or replace it with a working one. The reference doesn't need touching. There's more on diagnosing that state in Power Automate: Invalid Connection.
Custom connectors break after copying an environment
Cause: custom connectors use an environment-specific identifier, so a copy environment operation leaves the old references pointing at something that no longer matches.
Solution: create a new connection reference to the new custom connector, then fix any apps or flows still using the old ones. Related to this, custom connectors need to be imported in a separate solution, before the connection references or the flows that use them.
Final Thoughts
A connection reference isn't a different kind of connection, it's a name that points at one. The connection holds the credentials, the reference holds nothing but the pointer, and your flow only ever talks to the pointer. Once that lands, the rest follows on its own: moving a flow between environments means aiming the same name at a different connection, and a broken connection doesn't mean a broken reference.
Environment variables are the same idea applied to the values a flow depends on, which is why the two usually show up together in a solution.
Sources
Photo by Chelsey Marques on Unsplash
No comments yet
Be the first to share your thoughts on this article!