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.
You can also subscribe and get new blog posts emailed to you directly.
About The Author
Benedikt
Power Platform Consultant @ CRM Konsulterna
How can other developer access the Service principal connection reference when they build an flow? The same connection ref that i created in my flow? The connection and connection ref are very connected to one user no matter if its an service principal connection. Its still owned by the created user.
How do you solve that? . They cant be that they should create their own connection ref with same service principal. We will end up with many connection ref, and in automated deployment its hard.
Any ideas?
I can go into their flows and ad my connection and then they can use it furturer down the flow. But i still need to go into their flows as is now.
Thanks for your comment.
If you create a connection reference everyone (who has access to the solution) should have access to the connection reference (Connection references from Canvas Apps are a different thing).
Connections on the other hand are user-specific, so every developer would have to create its own connection and then assign it to the connection reference.
A connection reference does not contain any actual credentials, which means it can’t be for a service principal. What we usually do is create a connection reference we intend to use with a service reference and change the name as shown. In the end, you still could assign a connection using user credentials.
In regards to “sharing” connections. As I mentioned in the post there is no GUI for doing that, but the process you described will share the connection somehow in the background. I hope this will be improved with the feature “Greater control over connection reference creation and reuse during flow creation” of the release 2022 wave 1.
Hi Benedikt,
Thank you for writing this article and demystifying connection references. Following “D365’s” comment, I believe I have encountered the same problem and I understand what he’s trying to say.
When a connection reference is created in an environment, it has an owner who is the user who created it. That same connection reference can be seen in an environment by other users and can be added to solutions as well. But as a user who is not the owner of the connection reference, when you try edit a flow or create a new flow, that connection reference is NOT initially visible when you click the three dots next to a connector. As another user, you only have the option of using
a normal connection or creating a connection reference of your own.
However, when you try do the same action as the original owner/creator of the connection reference, you are able to see it in the dropdown and select it on a connector even in a flow you do not own. It seems as though the connection references are tied to a user account as well which is a very big drawback when working in a team of multiple devs/app makers. This article talks about this in greater detail
https://community.dynamics.com/crm/b/crminthefield/posts/considerations-when-using-connection-references-with-power-automate-flows.
Hej Brian,
thanks for the explanation. Now I do understand what was meant.
Yeah, that is a problem which I have seen earlier as well. It was usually fixed for me after adding myself as the owner and opening the flow a couple of times.
I am working with a client and seeing some strange issues with connection ref and SQL Server. We have been using s service account when importing a number of solutions and then setting up the connection ref with this account. What I am seeing is users getting requests to authorise when opening up each app. I go into the default solution and locate the connection ref and I am presented with with a guid and not say a server name string. Are the limitations on how may connections a service account can support ( I thought it was 16) . Do you advise may separate solutions sharing the same connection ref – so not needing to set up a connection each time , when importing a solution?
Hej Daniel,
there are some limitations and we also run into them from time to time.
The limitation of how many flows can use a connection ref was recently lifted.
I would try to reuse the connection ref in as many flows/apps as possible. A Prerequisite is that you plan to use the same connection. For example, there might be the need to use different accounts to connect to the same database from different flows/apps. In that case, you would need one connection ref per account. But if it really is the same account I would reuse the conn ref.
Problems could arise when you use them across solutions. This would add a dependency between those solutions which might lead to errors further down the road. The general recommendation from MS is to have one solution per environment.
Thank you for this Benedikt, I was just wondering what happens when the owner of “Connection” leaves the company. I see that although I can configure connection to use service principal, the owner is still my user. I wonder if this can be a problem when my user gets disabled or deleted. I see also that I can share connection to service principal, maybe it won’t be a problem in that case?
Thanks in advance
Hej Zarko,
afaik the connection would be inactivated/deleted when your account will be. As with flows this should be prevented when you share the connection with a Service Principal.
Hi,
Question on “best practices” for using conection references :
Do you create a new connection references for every solutions or do you have “generic” connection references for every type of connect
ion in an environment that you use across multiple solutions ?
Hej Rudi,
very good question. We do vary a little on that in different projects.
When we develop parts we try to use the same connection reference for everything.
There are a few reasons why we would create several connection references even to the same connector.
There might be other reasons. But trying to minimize the amount of connection references is a good idea.
Hope it helped. Let me know if you have any further questions.
Benedikt
Can we connect Commerce Scale Unit with Power Apps?
I have to design a form where data will fetch Store Commerce Scale Unit DB in real-time.
Is it possible?
I assume you are talking Dynamics 365 Commerce. I never worked with Commerce Scale Unit. I can’t see that there is a connector for that part of commerce yet. But if there is an open API you could create a custom connector and use that in both Canvas Apps and Power Automate.
Hi Benedikt
Great site.
I’m setting up pipelines in PowerAutomate and I wonder how I can solve the issue of connections.
I’ve read your post about using AzureDevops and a settings file.
Is there a similar thing in the PowerPlatform Pipelines?
Hej,
thanks for your comment.
Pipelines in Power Platform (PPP) do also use settings underneath. When you deploy a new connection reference the first time using PPP you have to select which connection should be used. In the background this will create (or update) a settings file which will be used for every following deployment.
Hello, Benedikt. Why should we consolidate connection references? What are the benefits of doing this?
Thank you for a great article!
Hej Noah,
thanks for your comment.
The main reason would be maintainability I would say. It get’s much easier to maintain the right connections when there are as few connection references as possible. Also changing the connection is easier and faster since it only has to be done in a few places.
Hope it helps.
[…] Apps, Flows and Connections can often times be challenging, especially for those new to the Power Platform, so I thought I […]
Hello Benedikt. We are getting this error with a couple of our Power Flow connector actions, when using them in Copilot Studio (PVA) topics: “Connector action: User (C2) connections must use Azure Active Directory authentication.” Copilot Studio has been configured for “Manual Authentication” using Entra ID (AADv2). We are trying to get the Entra ID authenticated users email address automatically for subsequent actions in Zendesk. Any advice will be appreciated. Thanks!
I never had this problem. Are the users authenticating against EntraID or a different provider?
[…] one of my older posts, I described how connections and connection references work. I still often get asked how one can […]
[…] one of my older posts, I described how connections and connection references work. I still often get asked how one can […]