Connection references and permissions in Power Automate

Have you ever battled with connection references in Power Automate? If not, you probably haven’t worked on projects with multiple developers or you aren’t using solutions to deploy your flows. In this post I’m covering how to deal with connections, connection references when you have multiple developers.

Connections

Before I look at Connection references I will have a look at connections. What are connections?

Connections provide all that is needed to authenticate to an application’s connector. So to create a connection you often supply a user name and password and then the connection is set up. Don’t worry, your connection does not keep your username and password. It all works with tokens Your user name and password are only used to generate the token for you.

If you have followed my blog for a while (if not you will find the subscribe button at the top right or at the bottom of this post), then you will know that you should always setup environments for Development, Test, UAT and Production. Then you can use solutions to deploy everything that is related to your apps and flows. So how do we deploy connections? Well, we can’t deploy connections.

Connections are:

1. Personal or at least connected to an account.
2. Specific to an environment

Connection references however are deployed using solutions.

Connection references

What are connection references?

Connection references are a shell around the connections. Connection references are used by, for example, actions within a flow. Then when the flow runs a connection is used that sits within the connection reference.

Now if I run the same flow as two different users, one user may see a successful flow run while another user may get a Forbidden message.

When we investigate the issue further we will find the following error

System.UnauthorizedAccessException – “Attempted to perform an unauthorized operation.”

When we see this issue we are running a flow as a different user while we aren’t allowed to do this. So for example our first user has access to a SharePoint site while our other user doesn’t have access to the same SharePoint site.

So even though we use a single connection reference on our action, we get different behaviours as each user runs under their own account. When we review the connection within our flow we find our connection reference back.

And when we review the connection reference a bit further we will find that for each user there is a separate connection there.

This is where it is important to understand how a flow is started. Quite a while ago I wrote a post about different flow types. So we have the following three flow types:

• Manually started flows
• Automated flows
• Scheduled flows

Manually started flows will run as the user starting the flow.

Scheduled flows will run as the owner of the connections. I often hear people say that they run as a owner of the flow but that is not completely true as it is possible to add an action that uses a connection that is shared with you.

Automated flows run like scheduled flows as the user specified in the connection. You can test this with a flow When an item is created and get the flow to create a file. The file created will always be owned by the same user account.

When you develop flows, you should make sure that you only use a single connection reference unless there is a good reason to use multiple connection references. For example if your flow connects into multiple sites across multiple tenants

Creating Connection references

In my earlier screenshots you might already have noticed that I had two types of connection references.

The first connection reference is called  SharePoint ConvertCSVtoJSON-8f4b0 while the other one is called SharePoint Solution1-30e7d

From within the solution I can rename my connection references. The above examples were connection references that were created as I added an action to my flow. The random characters at the end of the connection references only pollute my naming standards.

In general, I do prefer to include the connector name ( in this case SharePoint) and the solution or product name. Sharing a connection reference between multiple application is not a good idea. Creating your connection references before you start developing your flow is even better as you end up with nice cleanly named connection references.

Multiple developers – aaahhhh

Now that we have looked at connections and connection references, we can have a look at the situation that appears when we have multiple developers working on flows.

You could of course use a single shared account that owns all flows and all connections. Now we all edit the flows with that same account and nobody knows who did what. From an auditing perspective this is a big NO.

So how do we resolve this?

You could use a shared/service to do the initial work of adding an action with the right connectors to your flows before doing any additional work with your personally named accounts. Why? I’ll show you a bit of the ins and outs here.

I have my two accounts again and I asked my colleague to create a flow with a SharePoint action. The connection reference is set to SharePoint Solution 1.

Now when I’m going to edit the flow myself, I can see two connection references whereas my colleague only had one connection reference available.

This means that when you have multiple users developing your flows you will end up with at least as many connection references as colleagues. To keep the system clean we want to reduce the number of connection references.

Now this is where it is important to created a leading account (shared or service account as mentioned earlier). Using that account we can assign the single set of connection references to the actions in our flows. Once that has been done, problems solved.

Once a connection has been introduced to a flow any user with access to edit the flow can now use the connection reference.