Power Automate Standards: Connection References

Power Automate Standards: Connection References
Table of Contents
• Use Connection References Instead Of ConnectionsRemove Duplicate Connection References From SolutionsDe-duplicate Connection References In EnvironmentsAssign 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.





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.

Subscribe
Notify of
guest

17 Comments
Oldest
Newest
Inline Feedbacks
View all comments
Gianluca M
Gianluca M
1 year ago

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…

Daryl James Vogan
Daryl James Vogan
10 months ago

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?

Daryl Vogan
Daryl Vogan
10 months ago

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?

Piotr A
Piotr A
10 months ago
Reply to  Daryl Vogan

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)

Rubén L
Rubén L
7 months ago
Reply to  Piotr A

Did you solve it? We have the same issue.

Roland
Roland
2 months ago
Reply to  Rubén L

If the connection reference is in the solution you’re working in, just edit the connection reference and set it to use your own connection. You can then choose the connection reference in the flow’s actions. Each dev will need to perform this every time they need to work in a flow, so it tends to become a PITA quite quickly.

Noah Masimore
Noah Masimore
10 months ago

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!

Piotr A
Piotr A
10 months ago

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?

Sean Hodkinson
Sean Hodkinson
9 months ago

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

Matt Ruma
8 months ago

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.

Leo
Leo
2 months ago

Great article thanks. So in short, when creating a new solution, should we create all new connection references within this solution or use existing ones in the environment? I’ve read of people making a solution of just connection references, do you suggest this?

Roland
Roland
2 months ago

I’ve found out that any write actions in Dataverse that are performed by/through a flow, show the connection reference’s connection owner as the one who performed the write action. So in a team of 4 consultants working on a project for a client, whomever owns the connection that’s set in the connection reference at runtime of a flow, is the person who supposedly performed the actions (say, update a contact or add a lead).

Clients don’t appreciate this, as its confusing to see external users as having created/modified records, not to mention what happens if/when accounts get deactivated.

Would you recommend adding an account that’s only used to be the owner of connections, or is there a way to make the connection references independent of a specific user’s connection and have them act as though they’re using the SPN’s connection?

Dean
Dean
1 month ago

I have run into lots of problems when sharing connection references between different solutions due to dependencies. I frequently need to export my solutions to different tenants and run into fewer problems if I create connection references for each solution e.g.

Timesheets: SharePoint, Timesheets: Office 365 Users
Inspections: SharePoint, Inspections: Office 365 Users

It results in a lot of duplicate connection refs but I find it makes solutions more maintainable.