What it does

A connection reference is a solution component that points at a connection instead of the app or flow binding to that connection directly. On import into a target environment you supply a connection for each reference, and everything bound to it comes up pointing at the right credentials without editing the app or flow.

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.
• Connection references are created automatically when you create a connection from the flow designer or Power Apps Studio inside a solution.
• Apps and flows added to a solution from outside are not upgraded automatically. A flow keeps using direct connections until you export and reimport it in an unmanaged solution, or use the flow checker's Use connection references action.
• Canvas apps associate a connection reference only at the point a data source is added. Upgrading an app means removing the connection and re-adding it — and on a managed solution, editing the app creates an unmanaged layer.
• Canvas apps don't recognise connection references on custom connectors at all. After import you have to open the app and remove and re-add the custom connector connection.
• To turn a flow on, the user doing it must own or have permission to use every connection the flow uses. Otherwise you get ConnectionAuthorizationFailed.
• OAuth connections can only be explicitly shared with a user representing a service principal. You cannot hand an OAuth connection to a colleague.
• Once a flow has been turned on by the owner of its connections, it holds explicit permission to use them and any co-owner can then turn it off and on.
• There's no longer a limit on how many flows can reference the same connection reference, or on actions per flow using one. Updates are applied asynchronously.
• Connection reference ownership can't be transferred from the modern Solutions area. The classic solution explorer can change privileges including sharing.

When to use / skip

If the solution moves between environments, connection references aren't optional — they are the mechanism that makes deployment repeatable. The real decision is whose connections sit behind them, and the answer is almost always a dedicated service account rather than a person. Direct connections are acceptable only for a flow that will live and die in one environment and that nobody else will ever need to maintain, which is a smaller set of flows than any client believes.

Configuration decisions

• Which identity owns the connections in each environment — a service account, a service principal, or a named person you'll regret later.
• Naming, because the default includes the connector, the solution name and a random suffix, and a solution with fifteen of those is unreadable.
• Whether connection references live in the same solution as the apps and flows that use them, or in a shared base solution.
• Custom connectors go in their own solution, imported before the connection references and flows that depend on them.
• How connection sharing is granted at deployment: manually, or automated through the Edit Connection Role Assignment action on the Power Apps for Makers connector.

Gotchas

• When a maker leaves, every flow using their connections stops working. Turning them back on requires someone who owns or has been granted the connections, and if those were OAuth connections owned by a departed user, there's nothing to grant — you rebuild.
• Copying an environment breaks connection references for custom connectors. Custom connectors carry an environment-specific identifier, so you need new connection references and then fixes to every app and flow that used the old ones.
• Importing an implicitly shared secure connection via a connection reference has a known issue where the security isn't set correctly in the target environment.
• Solution import using a service principal can fail unless the connection is shared with that service principal.
• Editing a managed canvas app to fix a custom connector connection creates an unmanaged layer, which then has to be managed for the life of the solution.

Consultant notes

• Set up the service accounts and their connections in every environment before the first solution import. Doing it after means reworking every connection reference by hand.
• Put "what happens when this person leaves" on the risk log with a name against it. It's the most predictable production outage on the platform and it's always treated as a surprise.
• Warn the client that custom connectors need their own solution and their own import step. Teams discover this during their first failed deployment, usually on a Friday.
• Service principals are the right long-term answer for connection ownership, and they're also the one identity type OAuth connections can be shared with. Raise it early — getting one provisioned takes longer than the work it enables.

---

Worth revisiting if canvas apps ever support connection references for custom connectors, or if ownership transfer arrives in the modern solution UI.