A question recently came up on Discord which I found interesting, as although the answer (hint: solutions) is the fundamental aspect of Power Platform development, the sharing and proper control aspect shows a great intent to achieve sustainable working practices (the entire intention of setting up this site).

Is there a blog or information on best practices regarding custom connectors, connections and connections references and how should these be managed in multiple environments? How should these components be shared among devs for proper control?

What are these?

This has been covered in various articles previously and I will not go into the detail of automation, etc as it is covered heavily in the Azure Devops series. But as a brief intoduction to the concepts:

• Connectors: Sevices available to be used by Power Automate, Apps, Copilot, etc.
  • Outlook, Onedrive, Dataverse, Twitter, SQL Server, etc.
• Connections: The account/details with which you will connect to these services. Note – this account will obviously need permission to access these services.
  • Personal/service interactive account, SQL database username/password, external service API key, etc.
• Connection references: Items within solutions that flows use, which in turn point to connections. This prevents the flows using connections directly.

Why do I need references?

If your flow uses a connection directly and it needs to access the service as a different account, the connection will need to change. In turn, the flow will need to be edited. This in turn will mean you have different versions of the flow in different environments, fundamentally defeating the main purpose of multiple environments.

Connection references being used by the flow means the connection (and in turn the account used) can change with no effect on the flow and in turn, reduced risk. This does not mean any changes should happen in non-dev environments, but the concept stands.

How to use in different environments?

Solutions. Regardless of references, flows, apps, you should always use solutions. All customisations (flows, apps, variables, JS, etc) should exist in a number of solutions that suit your use csae and changes are only ever done in the unmanaged solutions in dev. These should then be exported as managed (I’d recommend automatically, see my previous articles covering this). This will prevent any changes being made in those environments and ensure stability of your test and live environments. Microsoft also have a feature coming soon where you can completely lock down an environment to not allow customisations at all.

When you import, If you wish to change the connection it uses, you simply repoint the reference to that connection. Easy and safe.

Sharing between devs?

Using them in dev between multiple devs is a slightly strange answer. If you have a flow that already has an action, let’s say send an email for the Outlook connector – even if that action uses a connection reference that points to another devs connection (this is legitimate in dev) it will continue to work and you can still edit the flow, even if you add more Outlook actions.

The difficulty comes when you want to add new connectors to that flow. Let’s say you want to add a row to Dataverse – even if you have a connection reference that will be exported, you may not be able to see it within a flow that does not already use it. Sometimes it will work, but if it doesn’t, the reason is almost always because you cannot see the connection the reference is pointing at. To solve this, ensure no one else needs to edit flows for it and change the reference to point at one of your connections, it will then work no problem.

Please note an important point: This is dev environment only. Your references should always point to connections owned by a service account in test and live environments (where managed solutions exist), as this avoids issues such as people leaving and accounts being deactivated or deleted.

If Microsoft make this better in the future (ideally being able to share connections), I will cover it in an article, as it will have a big impact.

What about custom connectors?

See above. References will point to connections for your custom connector like connections for any out of the box connector, the behaviour is no different in any way. Obviously it goes without saying, like any customisation – include your custom connector in a solution to export to other environments.

Summary…

I hope this gives a simple but understandable explanation of why and how to use connections and references. I am always happy to clarify anything, please comment here or leave a comment on discord or post on the Reddit community.

Also, as this is the first community question, please feel free to ask for anything you would like to know and I will try to address it in an article.