Power Platform Connections and Identities: Connection References vs Connections

Introduction

In enterprise Power Platform development, two key considerations are how your flows connect to services and under what identity they run. Getting these right is crucial for Application Lifecycle Management (ALM), security, and maintainability.

In this article, we’ll clear up the confusion by focusing on these often-misunderstood concepts:

• Power Automate Connections vs. Connection References: Understanding how flows connect to external services and how to make those connections portable across environments.

We’ll explore what each term means, their differences, real-world use cases, and best practices. By the end, you should know how to design flows that won’t break when a developer leaves, how to promote flows between environments smoothly, and how to secure high-impact automations with the right type of account.

Connections vs. Connection References in Power Automate

In Power Automate, a connection is the authenticated link between a flow and an external service (like Microsoft 365, SharePoint, Dataverse, etc.), using specific user credentials. A connection reference is a pointer or alias to such a connection, used within solution-aware flows to enable easier maintenance and deployment across environments. Understanding the difference is essential for ALM and multi-environment deployments.

Connections: When you add, say, a SharePoint action to a flow, you sign in with your account — that stored credential becomes a connection. The connection is tied to your user identity and the current environment, and it contains the auth details (like OAuth token or API key) needed for the flow to act on your behalf. If you directly use connections in a flow and later need to switch to a different account (or if the original account is disabled), you would have to edit every action in the flow that uses that connection to update it. Connections are typically used in non-solution (standalone) flows or personal productivity scripts.

Connection References: A connection reference is an abstraction layer above connections. It lives inside a Solution (the mechanism for grouping and moving components in Power Platform) and simply references a connector + connection combination, without embedding user credentials itself. The flow’s actions are bound to the connection reference (not directly to a specific user’s connection). This indirection allows you to change which actual connection is used (e.g. swap to a service account’s credentials) in one place, and all flow steps will use the updated connection automatically. Connection references make solution-aware flows far more portable between environments (Dev → Test → Prod) because you can map the reference to appropriate connections in each environment without modifying the flow logic.

Non-solution vs. Solution flows: In practice, non-solution flows (those created outside of a solution) use direct connections, whereas solution-aware flows require using connection references. This design is intentional: it ensures that solution-aware flows can be moved across environments via solutions and then easily wired up to new connections in the target environment. It’s best practice to always build flows inside solutions for anything beyond one-off personal use. This way you’ll be using connection references, unlocking benefits we’ll discuss next.

Why Connection References Matter (Real-world Scenario)

Imagine you have an approval workflow that uses Outlook and Dataverse connectors. A citizen developer built it quickly in the default environment using their personal Office 365 connection. It works fine — until that employee goes on leave or leaves the company. Suddenly, the flow breaks because the connection was under that user’s credentials, which are now disabled. This is a common issue when flows are tied to individual accounts. The fix is often manual: an admin has to reassign or re-create connections under a different user and update each action in the flow. Not only is this tedious, it’s risky — you might miss updating one of the actions, causing part of the flow to still run as the ex-employee.

Now, consider the same scenario built as a solution-aware flow with connection references. The connection reference might be configured to point to a service account’s connection instead of an individual’s. If the original maker leaves, it doesn’t matter — the service account remains, and the flow continues running. Even if you did need to change credentials, you would simply update the single connection reference to use a new connection (maybe a different account or a Service Principal connection), and all actions would immediately start using it. No need to edit the flow steps individually.

Another scenario: you need to deploy the flow from development to production. With connection references, you can import the solution and then rebind the connection reference to a production connection (for example, the SharePoint connector in Prod might use a Prod service account). The flow doesn’t need editing; it picks up the correct connection via the reference. Without connection references, moving a flow to a new environment means opening it and reconfiguring every connector to sign into the production data sources, which is time-consuming and error-prone.

ALM and new features: Connection references were introduced to facilitate Application Lifecycle Management (ALM) for Power Automate. They decouple the flow design from the specific user auth. This not only aids environment transfers but also enables features like the Modern Flow Designer and future enhancements. In fact, if you put an older flow that uses explicit connections into a solution, the system will prompt you to convert those to connection references. In one example, a flow added to a solution showed a warning that the new modern editor wasn’t supported until connections were converted to references. The maker used the Solution checker (or Pro Checker) to automatically convert all connections to connection references with just a few clicks. After conversion, the flow was fully solution-compliant and could even be edited in the improved designer.

Best Practices: For any flow that is not purely personal or throwaway, use connection references. Specifically:

• Use Solutions and Connection References for shared or production flows. This ensures flows have ALM support, versioning, and environment portability built in.
• Avoid hard-coding personal connections for long-term or team-owned flows. Instead, use a service account or service principal connection (more on this shortly) referenced via a connection reference. This shields the flow from disruptions if individuals leave.
• Consistent naming convention: Name connection references clearly to indicate their purpose and environment. For example, “CRMDataverseConnRef_Dev”, “CRMDataverseConnRef_Prod” — this helps identify the right reference during deployments. It’s common to include the connector/service name and environment in the reference name for clarity.
• Reuse connection references when appropriate: Multiple flows in the same solution can use the same connection reference for a given connector if they share the same credentials. For instance, if several flows all need a Dataverse connection with the same account, you can create one reference and have them all use it. This way, updating the credentials or connection in one place updates all the flows. (You can also have multiple references using the same underlying connection if needed — e.g., two references pointing to two different SharePoint sites, both authenticated via the same service account connection.)

Power Automate’s flow designer allows adding a new connection reference for a connector action. In this screenshot, the maker is adding a Dataverse action and can choose “+ New connection reference” to create a reference instead of using an existing connection. Connection references act as placeholders that will be linked to an actual connection (with credentials) in each environment. By using references, the flow isn’t locked to a single user’s credentials during design time.

Overall, connection references make your flows more robust and enterprise-ready. They support scenarios where flows need to be deployed across multiple orgs, managed by multiple people, or simply kept running beyond the tenure of their original creator. They are foundational for good ALM practices in Power Automate.

References:

• Microsoft Learn — Solution-Aware Flows and Connection References learn.microsoft.com
• Benedikt Bergmann — Connections and Connection References explained