Considerations when using Connection References with Power Automate flows

It has been a while now that we have had connection references available within Power Automate. Many are becoming more familiar with using these and as the adoption grows, there are some scenarios that I want to cover with the community. These are primarily focused on scenarios where they are multiple developers/makers working in an environment.

Lets make sure we cover some of the basics first.

Connections - These are user owned and specific. There is no concept of sharing connections, even if you share a flow. There is also no visibility to view or use another user's connections in an environment.

Connection Reference - These are also user owned and user specific. It is the link between a user, an action within a flow and the connection to that specific data source. If a user has the proper security privileges, they can see connection references owned by other users within Solution Explorer. However, if they Edit the connection reference, the connection will show blank, because you cannot see other's connections. This can cause some confusion.
 

For example, TestUser created a connection reference using their own connection. When I sign in as my personal user, this is what it looks like when I look at TestUser's connection reference:

It looks as though it is not assigned to a connection, when it actually is. If I change this connection as my user, it will update any flow using this connection reference to then use my connection instead. Now, if I look at if from TestUser's account, you will see it is actually using a connection:

Scenario 1:

We will look at how this works in a scenario with only one developer/maker creating flows who is also doing the import of the solution into the destination environment. This is more common for a smaller deployment.

TestUser creates a new solution with a new flow that uses their Dataverse connection and their connection reference (TestUserDataverse).

TestUser then export this from the Originating environment into the Destination environment. When the do the import, they will be prompted to fill the connection reference with a connection THEY own. If they don’t have one, they will have to create one. This prompt occurs because the connection reference exists in the solution and does not yet exist in the Destination environment.

After this has been imported, the Flow is enabled and using the proper connection and connection reference. All is well.

Now, we will look at what happens when you have multiple devs/makers working on flows

Scenario 2:
This scenario is looking at multiple developers/makers creating and modifying flows in an environment where they would continue building on the flow using another user's connection and connection reference.

1. TestUser creates new flow in Originating environment with a connection reference they own (TestUserDataverse)
2. TestUser exports the solution and imports into Destination environment and is prompted to select connection to tie connection reference to
3. User AR navigates to this flow. Aaron has no connection or connection reference of their own in Destination environment

1. User AR Looks at existing Actions and can see TestUserDataverse connection reference owned by TestUser

1. If User AR modifies this flow by adding another step, he can continue using the connection reference owned by TestUser. This is expected and by design on an EXISTING FLOW. If User AR creates a new flow, he can still only see his own connection references. When the flow is built within a solution, which is a best practice, sharing the flow has no impact here as long as both users have proper security privileges (in this case, System Admin)
2. User AR could also create their own connection reference and modify the flow further

Scenario 3:

This scenario looks at multiple users building flows within an existing solution, which already exists in the Destination environment that were originally imported by one user, but the updated solution being imported by another user.

1. TestUser adds a new flow to the existing solution in Originating environment using TestUserDataverse connection reference. Both the flow and connection reference are owned by TestUser in originating environment.

1. User AR exports this existing solution from Originating environment and imports to Destination environment

1. This solution is imported to Destination Environment by User AR and still owns no connection reference or connection
2. No prompts occur when User AR imports to Destination Environment to link the connection reference to a connection. This occurs because the connection reference already exists in the Destination Environment.
3. Now, when User AR looks at this flow, they see it is OFF, there is NO connection references assigned to the flow and states there is a potential problem with this flow. This is also owned by User AR (Aaron Richards) since they did the import

1. When opening the flow, they see the following:

1. If User AR clicks continue, it will automatically create a connection reference owned by User AR and assign that to the flow instead. If User AR clicks continue and does this in a managed solution, it will create an unmanaged layer on top of the managed layer due to this change and may cause deployment issues.

Why does this happen? It is due to the lack of visibility for User AR to see the connection owned by TestUser during the import. This is something the product group is actively working on.

Scenario 4:

This scenario looks at multiple users building flows within a new solution, which uses connection references that already exist in the Destination environment (from another solution import) that were originally imported by one user, but the new solution, containing new flows, being imported by another user. Another common scenario of this is creating a solution that contains all connection references and importing to all environments as one user and new flows and solutions being imported by other users

1. TestUser creates a new solution with ONLY a new flow in Originating Environment and is imported by User AR to Destination Environment. The flow is using a pre-existing connection reference TestUserDataverse
2. No connection references are included in the solution.
   
3. User AR receives no prompts for linking connection references used in the flow to a connection when importing to Destination Environment
4. Again, no connection references are assigned to the flow and states there is a potential problem with this flow. The flow is OFF and when clicking edit is prompted to reconnect. This is the same result as Example 3 and occurs because the connection reference already exists in the Destination Environment but is owned by TestUser and linked to TestUser's Dataverse connection

Scenario 5:

This scenario looks at multiple users building flows within a new solution, which uses connection references that already exist in the Destination environment (from another solution import) that were originally imported by one user, but the new solution, containing new flows AND existing connection references, being imported by another user.

1. TestUser creates a new solution with a new flow in Originating Environment and is imported by User AR to Destination Environment. The flow is using a pre-existing connection reference TestUserDataverse, which already exists in Destination Environment

1. The connection reference (TestUserDataverse) is included in the solution
2. User AR is prompted to update this connection reference during import to Destination Environment. Since he does not yet own a connection, he must first create one.

1. When this is done, it now overwrites the connection on the pre-existing connection reference owned by TestUser in Destination Environment. This means that any flow using that connection reference will now start using the connection owned by User AR (aaronric) as seen here instead of TestUser.

Recommendations:

The best method to work through these issues, until they are addressed through the product, are as follows:

1. Ensure the person doing the import into higher environments is the same person each time, who will own the connection to the data source as well as the connection references that are being imported. This will prevent the issue of connection visibility from breaking flows upon import and overwriting connection references.
2. Have developers/makers use a shared account (service account) that each person logs in with so that the connections and connection references are always owned by that account, which should also be doing the solution import.

Note: These same examples are valid for both manual import and automated deployments, as well as with using Service Principals.

Thank you for reading.