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.
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.
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.
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?
Leo,
If you have sole ownership of the environment create only one set of connection references and reuse them for every flow.
When deploying into an environment used by multiple parties, create new connection references so you can manage them separately from everyone else’s.
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?
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.
Hi Matthew,
Curious if you have run into the issue where Power Platform connections fail if the device they were created on becomes disabled in Azure/Entra. My organization recently had a large number of connections stop working due to my old workstation being retired. Our connections use a service account.
Turns out that the auth token has a deviceID, and if that device is no longer active, boom, everything breaks. I have worked with both Azure and Power Platform support to learn that this is currently ‘by design’.
Below is the error I received when looking at the connection itself in the Power Platform
Failed to refresh access token for service: sharepointonlinecertificatev2. Correlation Id=4df259f5-d7e7-4220-b893-22acf476aee4, UTC TimeStamp=9/12/2024 4:16:36 PM, Error: Failed to acquire token from AAD: {“error”:”invalid_grant”,”error_description”:”AADSTS135011: Device used during the authentication is disabled. Trace ID: 1000056f-a034-4ce7-9e15-0560fb7cc600 Correlation ID: 3fbe87c5-3d62-4868-ba5e-23e3b1e80c66 Timestamp: 2024-09-12 16:16:36Z”,”error_codes”:[135011],”timestamp”:”2024-09-12 16:16:36Z”,”trace_id”:”1000056f-a034-4ce7-9e15-0560fb7cc600″,”correlation_id”:”3fbe87c5-3d62-4868-ba5e-23e3b1e80c66″,”suberror”:”device_authentication_failed”}