Table of Contents
• Use Connection References Instead Of Connections
• Remove Duplicate Connection References From Solutions
• De-duplicate Connection References In Environments
• Assign Connection Ownership To Service Accounts
Use Connection References Instead Of Connections
Flow actions requiring authentication must use either a connection or a connection reference. Connections allow Power Automate to interact with other online services (SharePoint, Outlook, etc). Connections references do the same but they hold a reference to a shared connection instead of connecting directly themselves.
Always use Connection References to reduce maintenance efforts. Swapping out connections for a flow action must be done individually. Connection references can changed in one place and will update all connected flows. Fixing broken connections is much faster too.
Connection references in a managed solution can be updated without creating an unmanaged layer. Never directly edit flows in production and test environments to avoid introducing bugs.
Remove Duplicate Connection References From Solutions
There should only be one connection reference within a solution for each online service being accessed. Remove any duplicate connection references from the solution. The exception should be made when an online service must be accessed with multiple sets of credentials. For example, connecting to Outlook with two different Shared Mailboxes.
De-duplicate Connection References In Environments
In addition to removing duplicate Connection references inside of a solution, they must also be de-duplicated within an environment.
When multiple solutions are imported into an environment it is common for them to each include their own connection references.
Assign Connection Ownership To Service Accounts
A Service Account with the System Administrator security role should own the connections being used by connection references. This enables centralized management of connections under an account with elevated permissions.
Do not use a developer’s personal account as the connection owner. To change connection details another developer would have to login as the original developer.
Having a Service Principal own the connections would be ideal. However, Power Platform does not support the use of Service Principals under the Per User license. A more costly, yet higher capacity, Per Flow licensing plan is required.
Did You Enjoy This Article? 😺
Subscribe to get new Power Apps articles sent to your inbox each week for FREE
Questions?
If you have any questions or feedback about Power Automate Standards: Connection References please leave a message in the comments section below. You can post using your email address and are not required to create an account to join the discussion.
Very useful, indeed! I do also hope, Microsoft will give us the functionality to (re-)name existing connections in order to sort the mess that happens after a while. I think you all know what I mean…
Gianluca,
You can change the display name of an existing connection. That’s already a feature.
I appreciate all your articles. We’re running into thorny issues where devs get an error when trying to adda flow with a connection reference created by someone else. The original user has to add. Are you aware of this issue. Are we doing something wrong?
Matt,
we’re having issues. we’re using a svc account to create the connection references, but then our devs do not have access to them to use on an action.
what are we doing wrong?
I had the same problem. It seems that if you are not the owner of the Connection Reference you are not able to use it (by use I mean selecting it from available Connection references)
Did you solve it? We have the same issue.
Hello, Matthew. Thank you for this article.
You recommended that we de-duplicate connection references in solutions, and de-duplicate connection references in environments. Can you explain why?
Thank you!
Noah,
Less components, less to maintain.
Thanks for your post Matthew. I recently had an issue with Connection References that within a team we don’t see the each others Connection References. How can I use the Per Flow licence to use Service Principal?
Hi Matthew,
love this series of standards.
You mentioned that Service Principal needs a per flow license rather than a per user license. Do you know if that has changed in recent times? Do you have any documentation on that?
Thanks,
Seán
Sean,
A service principal application user is a non-interactive user, so it can’t have a user license associated with it.
https://learn.microsoft.com/en-us/power-automate/service-principal-support#licensing-requirements
For a more complex application, with multiple solution layers, would it ever make sense to put all your Connection References in a single solution? Easier to manage? Curious.