How to work with connection References

In one of my older posts, I described how connections and connection references work. I still often get asked how one can properly work with connection references since a few problems always occur. In this post, I will explain everything you need to know about how to work with connection references in the area of flows.

Recap

Let’s first have a short recap of the mentioned blog post to get us all on the same page about what connections and connection references are.

Connections can’t be part of solutions, are not solution-aware, and therefore can’t be deployed to another environment. They also are user-scoped and depending on the connector can’t be shared with other users. For example, a connection to the Dataverse connector can only be shared with Service Principals (SPN) but not with other users.

Connection References are just pointers to a connection that should be used. They don’t represent any credentials to authenticate against a system. We can use those connection references to where we have access to the underlying connection.

Problems

Next, we have to talk about the problems that often occur when it comes to connection references. There are usually two questions or issues I experience.

The first issue is that when several people implement flows new connection references get randomly created now and then, without an understandable pattern.

The second issue is that flows get deactivated when a solution is deployed to a downstream environment.

Solution

In this section, we will learn how the problems described above can be dealt with.

Randomly created connection references

The first issue is two-fold, creating flows and changing flows. We need to understand both scenarios to understand the pattern when new connection references are created.

Updating flow

The first scenario is when someone would like to update an existing flow. This is always possible and even if you don’t have access to the underlying connection(s) you can use all connection references already used in the flow. This means as long as you stick to the connectors already used in the flow no new connection references will be created.

If you would add a new connector, which isn’t already used in the flow, it would act as if you would create a completely new flow. In that case, the next section will help you out.

Creating flow

The second scenario is the more interesting one. When creating a new flow, or adding a completely new connector to an existing flow for that matter, you can prevent the creation of new connection references if you have access to the underlying connection used in an existing connection reference.

If you do not have access to a connection used in any of the connection references to the connector in question the platform will automatically create a new connection reference for you.

Let’s explain that with a small example.
Person A creates a flow using the Dataverse connector. The system will automatically create a new connection reference. In the newly created connection reference, a connection to Dataverse owned by Person A will be used.
Person B creates a new flow also using the Dataverse connector. The system will automatically create new connection references using a connection owned by Person B.
Now we have two connection references to the same connector.

To achieve this we have to go into every connection reference we intend to use and change the used connection to one of our connections whenever we create a new flow.

This has to be done by every implementer whenever a new flow should be created.

When you open a connection reference and a “weird” id is shown in the underlying connection it means you don’t have access to it.
Here is an example of a used connection my user does not have access to.

Here is an example of a used connection my user does have access to.

ALM

To fix the problem with deactivated flows in downstream environments we should use Settings files. I wrote a blog post about them some time ago.

The basic process is to create a connection in a downstream environment, share it with the SPN used in our automation, add it to the settings file, deploy it with a pipeline and enjoy automatically activated flows.

Another Community member, Serhat Yildiran (LinkedIn), has recently created a great series on the topic of Settings files. Please go and check it out: Part 1, Part 2 and Part 3.

Tips & Tricks

As in the mentioned blog post where I explain connections and connection references, I would like to give you some tips and tricks when it comes to connection references. Some are the same as in the other blog post but the list got extended.

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 given 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”.

Create connection references

The best is to create your connection references manually before you try to use them. This makes sure that even the schema name is not automatically created with a random number as the suffix.

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 ones are used in the right places.

Use as few connection references as possible

We should try to have as few connection references as possible. This means also trying to have only one connection reference to every connector. Mostly to decrease management work on downstream environments.

There are scenarios where several connection references are needed. For example, if we need to use different users in the connections used in the Production environment.

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 deployment process.

Service principal connections

Try to use service principal connections wherever it’s possible. At the moment not a whole lot of connectors actually do support service principals.

Service user

One effective way of minimizing problems is to use a service user to own all connections in downstream environments. This means the user is used to create the connections, but the user does not need to be used in the connection. For example, we could create a connection to Dataverse with the user, but use a SPN in the connection.

Conclusion

Connection references are by far perfect. They have a lot of pitfalls and caveats even though they are better than what we had before!

If we have understood the different scenarios and why they work how they work it is manageable.

Most important is that we need to make sure we have access to a connection used in a connection reference to the connector we would like to use in our flow.

The post How to work with connection References appeared first on Benedikt's Power Platform Blog.

Original Post https://benediktbergmann.eu/2024/10/07/how-to-work-with-connection-references/