Connections and Connection References explained

In the last couple of weeks/months, I found myself explaining Connections and Connection References to several colleagues as well as community members while having conversations with them. Usually, questions about them came up along with other stuff we talked about. This made me think it might be interesting for the wider community to get Connections and Connection References explained. So here is another article in my “series” on stuff explained.

Basics

Let’s talk about the basics first and take a look at what Connections and Connection References are.

Connections

A connection contains all the information needed to connect a power automate step to a certain system. This could for example be Dataverse, SharePoint or any other. So basically for every of the 600+ Power Automate connectors or even custom connectors for that matter, one could create a connection.

Some connectors do have the possibility to create a connection as a service principal. One example is the Dataverse connector. This is especially useful to a) having a Service Account as the owner/modifier of data and b) making a flow decoupled to any particular user.

It is possible for a certain user to create several connections to the same connector. Dataverse connections using a Service Principal and personal credentials would be one example.

If you would like to learn how to set up a Service Principal for use in a Dataverse environment you can take a look at my blog post “Setup a Service Principal in Power Automate“.

Connection References

A Connection Reference is basically just storage for metadata. This means it just defines which connector is used and therefore which connection is needed. It doesn’t contain any credentials though. But in a certain environment, it always needs a connection configured to it.

Several Connection References can use the same connection and every flow could use several connection references for the same connector as well.

Entity model

The following picture shows the entity model behind Connections, Connection References, Flows and (custom) connectors.

Everything really comes together with connection references. A flow can have several connection references and a connection reference can be used in several flows (N:N relationship). A (custom) connector can have several Connections and Connection Referencs (both 1:N relationship). Lastly a connection can be used in several Connection References.

Idea behind it

One could ask the question why Microsoft decided to do it that way and not just have connections directly configured on Steps. That’s how it has been before MS introduced Connection References. The main problem was when someone wanted to change the connection to a certain connector.

Let’s say you have a Power Automate flow with 5 steps of the Dataverse connector and you used your personal credentials while creating the flow. If you would have liked to change all the steps to a connection using a Service principal you needed to change every single step within the flow before Connection References were introduced. This lead to several problems mainly an unmanaged layer in every downstream environment, since the flow itself needed to be changed. But since every step had to be changed manually there could be steps that were missed and used the personal connection still. Especially in big flows with a lot of steps and may be nested steps.

Now with connection references, one could just change the connection on the connection reference (which does not add an additional unmanaged layer) and every flow step using that particular connection reference will use the new connection in the future.

Handling

Let’s see how one can handle the different parts.

Change used connection reference

To change which connection reference a step is using you just click the three dots at a step and either select another Connection reference or create one.

As I mentioned earlier you can have different connection references for different steps of the same connector. One example could be to have an integration between two Dataverse environments. The “List rows” step connects to one environment where as the create/Update step to another. Here you would like to have 2 different connection references since you also need 2 connections later.

Change assigned connection

To assign a new connection to a connection reference you open the connection reference in the maker portal. In the opening sidebar, you can choose a different connection from the dropdown. You could even create a new connection from there.

Create Service Principal Connection

If you would like to create a connection to Dataverse using a Service Principal you need to do it via a workaround. It is not possible to create it via that “New connection” button you see in the last screenshot.

You have to create a new flow, change the used connection reference of a Datavese step and select “Connect with Service Principal”. In the next “screen” you can then provide all the needed information.

This will create a new connection reference as well. Make sure to clean that up imedieatly after, so that you don’t end up with a lot of old/unused connection references in your system.

Deployment

Next, we will talk about one of my favourite topics “Deployment”.

Connections are not “solution aware” and therefore can’t be moved between environments. Neither can they manually be shared with other users. This means there isn’t any UI for that so that one could explicitly share them with a certain user. However, they get shared automatically when one is configured as an additional owner of a Flow that was built by someone else. Then the second user should get access to the connection as well. In some cases, it is even enough if the second user just opens the flow.

Service Principal users can neither own nor can one share connections with them at all. This leads to problems when it comes to automated ALM. The flows get inactivated since the Service Principal can’t access the needed connection. The Release Plan for the Release 2022 Wave 1 does actually contain a new feature where Service Principals can own flows in the future. They can already own flows, but not connections which makes it basically unusable if they do.

Connection References are Solution aware and Flows do have dependencies on them.

If you deploy a solution containing a flow to the next environment the import process will ask you which connection you would like to use for every connection reference in the solution. This only happens once per connection reference, every deployment further one will just use the already assigned connection.

The (custom) connector has to be in the system already to be able to create a connection.

When it comes to automated deployment one has to configure which connection to use, please see my article about that topic for more detail.

Tips & Tricks

The last part of this blog post is my tips & tricks when it comes to Connections and Connection References.

Rename

Make sure you rename both your connections and connection references so that they have a giving name.

My usual schema is something like “<Area> – <Connector> – <Type>”. So for a Connection Reference to dataverse using a service principal which is used in our Absence app it would for example be: “Absence – Dataverse – Service Principal”.

Clean up Connection References

At least every now and then you should take the time to clean up all connection references. Best you do it before every release. With clean up I mean consolidate as many as possible, name them correctly and make sure the correct once are used in the right places.

Create connections before deploying

It is highly recommended to create all the needed connections before you start with your deployment. You are required to do so in an automated deploy process.

Service principal connections

Try to use service principal connections wherever its possible. At the moment not a whole lot of connectors actually do support service principals, but one item on the Release 2022 Wave 1 release plan (Service principal support for connectors) is giving me some hope in that matter.

Conclusion

I think Microsoft thought the concept of connections and connection references through. It also makes a lot of stuff easier, but one needs to understand it to really be able to use the pros.

I hope this post helped you in understanding connections and connection references.

If you have any questions or feedback please feel free to contact me.

The post Connections and Connection References explained appeared first on Benedikt's Power Platform Blog.