Connections vs Connection References in Power Automate: The Complete Guide

If you have ever moved a Power Automate flow from Development to Production and watched it immediately turn itself off — you have already met the problem that Connection References exist to solve. This guide walks you through both concepts from the ground up, explores where each belongs, and shows you exactly how to structure your flows so deployments never break again.

Table of Contents

1. What Is a Connection?
2. What Is a Connection Reference?
3. The Core Difference — Side by Side
4. Solution-Aware vs Non-Solution Flows
5. How Connection References Work Under the Hood
6. Creating and Managing Connection References
7. Deployment Across Environments (ALM)
8. Real-World Scenarios
9. Ownership, Sharing & Service Accounts
10. Best Practices
11. Common Gotchas

What Is a Connection?

At its most basic level, a Connection in Power Platform is a stored, authenticated link between a maker’s identity and an external service. When you add a SharePoint action to a flow and sign in with your Microsoft 365 account, Power Automate stores that OAuth token (or API key) as a Connection.

Think of a connection as the actual key to a door — it holds the real credentials.

Connections live under Data → Connections in your Power Automate portal. Each connection records:

• The connector type (e.g. SharePoint, Outlook, Dataverse)
• The authenticated identity — the user account or API key used
• The environment it belongs to

Because connections embed real credentials, Microsoft deliberately prevents them from being exported in solutions. This is a security boundary, not a bug.

What Is a Connection Reference?

A Connection Reference is a solution component that acts as a named pointer — or alias — to a connector type. It does not store credentials itself. Instead, it holds metadata and lets you map it to an actual connection at runtime.

The best mental model: a connection is the actual key; a connection reference is the key hook on the wall with a label on it. You can swap which key hangs on that hook without changing where the hook is installed.

Connection References are stored as Dataverse rows in the connectionreference table and carry:

• A display name and optional description (semantic labelling, e.g. “SharePoint – Service Account”)
• The connector type they represent
• A pointer to the actual Connection assigned in the current environment

The Core Difference — Side by Side

Solution-Aware vs Non-Solution Flows

This is the fork in the road that determines everything about how connections are handled.

Non-Solution Flows

These are flows created from My Flows → New flow. They live outside any solution and use direct connections. They are quick to create and useful for personal automations, but carry serious limitations for enterprise use:

• The flow binds every action directly to a specific user’s stored credentials
• Cannot be exported as part of a solution package
• When moved between environments, all connections are stripped and the flow is immediately turned off
• The maximum is 600 non-solution flows per user per environment

Solution-Aware Flows

These are flows created from Solutions → [Your Solution] → New → Automation → Cloud flow. They are Dataverse-backed, version-tracked, and use connection references. They support:

• Environment variables for values that change across Dev/Test/Prod
• Pipelines for automated deployment
• Flow run history stored in the FlowRun Dataverse table
• Unlimited flow ownership (no 600-flow cap)
• Co-ownership via Dataverse teams

Note: A non-solution flow can technically be added to a solution after creation, but this is discouraged. When added this way, the flow initially still uses direct connections. The Flow Checker will warn you to switch to connection references.

How Connection References Work Under the Hood

Understanding the data relationships helps you avoid confusing errors in team environments.

The N:N Relationship Between Flows and Connection References

This is the power of the model. A single connection reference (e.g. “SharePoint – Service Account”) can be referenced by dozens of flows. When the underlying service account connection needs to be updated or rotated, you make one change to the connection reference, and every flow that uses it is immediately updated — no flow edits required.

Creating and Managing Connection References

Creating a Connection Reference (Step-by-Step)

1. Navigate to make.powerapps.com → Solutions
2. Open or create your solution
3. Click New → More → Connection Reference
4. Fill in:
   • Display name — use a descriptive name (e.g. SharePoint – HR Service Account)
   • Description — optional but recommended for discoverability
   • Connector — choose the connector type (e.g. SharePoint)
5. Click Create
6. Assign a Connection — either select an existing one or create a new one

Auto-Creation During Flow Design

When you add a connector action to a solution-aware flow, Power Automate will:

1. Check if a connection reference already exists in the current solution for that connector
2. If yes → reuse it
3. If no → check other solutions in the environment
4. If still none → auto-create a new connection reference

Tip: To ensure the connection reference lives inside your own solution (not imported from another), create it explicitly before building the flow actions.

Viewing Connection References in a Solution

Inside a solution, select the Objects tab. Connection references appear as their own component type alongside flows, tables, and environment variables. You can see which flows depend on each reference directly from this view.

Deployment Across Environments (ALM)

This is where connection references deliver their biggest value — structured Application Lifecycle Management across Dev, Test, and Production.

Managed vs Unmanaged Solutions

When exporting a solution you choose between two modes:

Unmanaged solution — used in Development. The components can be edited freely in the target environment. Best for working environments where changes are made.

Managed solution — used for Test and Production. Components are read-only in the target environment. This prevents environment drift and accidental edits directly in production. Connection references in managed solutions can still be updated (to point to a different connection) without creating an unmanaged layer — a significant advantage.

Real-World Scenarios

Scenario 1 — The Employee Who Left

A citizen developer built an approval workflow using Outlook, SharePoint, and Dataverse directly in My Flows (non-solution). When this employee left the organisation, their Microsoft 365 account was disabled. The flow immediately failed because:

• Every Outlook action was bound to exemployee@contoso.com
• Every SharePoint action was bound to the same disabled account
• An admin had to manually open the flow, find each broken action, and rebind it to a working account — one step at a time

Solution-aware equivalent: The flow would use a connection reference named "Outlook – HR Service Account" pointing to a shared service account. The maker leaving has zero impact on the flow. If the service account credentials ever need rotating, one update to the connection reference propagates to every flow using it.

Scenario 2 — Deploying the Same Flow to Multiple Regions

Contoso operates in EU and US regions with separate Power Platform environments. They have an inventory alert flow that checks SharePoint lists and sends Teams notifications.

With connection references:

1. Build once in the Dev environment with "SharePoint – Dev" and "Teams – Dev" connection references
2. Export as a managed solution
3. Import to EU-Prod environment → map "SharePoint – EU Svc" and "Teams – EU Bot"
4. Import to US-Prod environment → map "SharePoint – US Svc" and "Teams – US Bot"

The flow logic is identical in all environments. Only the connection references differ.

Scenario 3 — De-Duplicating Connection References Across a Team

A team of five makers each built their own flows inside the same solution. Without coordination, each maker’s flow auto-created its own SharePoint connection reference — you now have five references all pointing to the same connector type, four of which are redundant.

Best practice: Before building, create a single canonical connection reference per connector per solution (e.g. "SharePoint – Main"). Share this approach with the whole team so they select the existing reference rather than creating new ones. This reduces maintenance surface significantly.

Ownership, Sharing & Service Accounts

This area contains several important nuances.

Who Can See a Connection Reference?

When you create a connection reference, other users in the same environment can technically see it if it is in a shared solution. However, there is a known limitation: another user cannot select your connection reference from the dropdown in the flow designer unless they are the owner of that connection reference, or unless it is already part of the solution they are editing.

The practical workaround: use a Service Account (a non-personal, shared user account with its own M365 license) or a Service Principal to own all connections and connection references used by production flows. This ensures:

• No single-person dependency
• Connections remain valid regardless of team changes
• Centralised management under a privileged account

Service Principal Considerations

Service Principals can own solution-aware flows, but cannot own connections under a standard Per User license. A Per Flow license is required for Service Principal support in Power Automate. This is a known architectural limitation worth planning around.

If a Service Principal owns a flow but cannot own its connections, the flow will fail. Always verify licensing before architecting a Service Principal-based ALM pipeline.

Enabling a Flow After Import

When a solution is imported, a user needs to enable (turn on) the flow. The person turning it on must either:

• Own all connections referenced by the connection references in the flow, or
• Have Can Use sharing permission granted on each connection

To automate connection sharing, you can use the Edit Connection Role Assignment action on the Power Apps for Makers connector.

Best Practices

Common Gotchas

1. Flow Turns Off After Import

Symptom: You import a managed solution into Production and the flow is immediately turned off.

Cause: Usually one of two things — the flow is still using a direct connection (not a connection reference), or the connection reference has not been mapped to a valid connection in the new environment.

Fix: Run the Flow Checker on the flow in Development. It will show a warning if direct connections are still in use. Use the “Remove connections” action it offers to switch to connection references. Then verify the mapping when importing.

2. Team Member Cannot See or Select the Connection Reference

Symptom: A developer adds a SharePoint action to a flow and cannot see the team’s canonical connection reference in the dropdown.

Cause: The connection reference is owned by a different user. In team environments, visibility of connection references in the designer dropdown is tied to the creator’s account.

Fix: Ensure the connection reference is inside the same solution you are editing. Each team member should be able to edit the connection reference directly (change which connection it points to) and then select it. The long-term fix is to use a service account as the owner of all connection references.

3. Multiple Duplicate Connection References Accumulate

Symptom: After several months, your solution has shared_sharepointonline_1, shared_sharepointonline_2, shared_sharepointonline_3 — all pointing to SharePoint.

Cause: Each time a maker created a new flow action without selecting the existing reference, Power Automate auto-created a new one.

Fix: Regularly audit connection references in your solution. Consolidate to one per connector per solution, then update all flows to use the canonical reference. Delete the redundant ones once no flows depend on them.

4. Canvas Apps Behave Differently

Canvas apps only use connection references for implicitly shared (non-OAuth) connections such as SQL Server with SQL Authentication. For standard OAuth connectors (SharePoint, Dataverse), canvas apps use direct connections even inside solutions. A connection reference is associated with a canvas app only at the time a data source is added. If you need to upgrade an app to use a connection reference, you must remove the connection from the app and re-add it via a connection reference.

5. Custom Connectors in Canvas Apps

Canvas apps do not recognise connection references on custom connectors. After importing a solution containing a canvas app that uses a custom connector, the app must be edited to remove and re-add the custom connector connection.

Environment Variables vs Connection References

These two concepts are often confused. They are complementary, not interchangeable.

Use them together for maximum portability: the connection reference handles who authenticates, and the environment variable handles where they authenticate to.

Summary

Connections are the actual credentials — environment-specific, credential-bearing, and not portable. Connection references are named, solution-aware pointers that let you swap the underlying connection without touching your flow logic.

For any automation that will be deployed across environments, maintained by a team, or run under a service account, solution-aware flows with connection references are the only correct architecture. They enable proper ALM, reduce maintenance risk when team members change, and make deployments repeatable and reliable.

The investment in structuring flows correctly from the start — building inside solutions, naming connection references descriptively, using a service account, and de-duplicating — pays dividends the moment you push your first deployment to production and the flow simply stays on.