The ALM story for Custom Connectors

This post is a part of a series of posts about custom connectors. In this post we will look at ALM for custom connectors. That story starts with the concept of Dataverse solutions. Here are my findings after working with custom connectors in solutions!

All parts of this series:

1. Revisiting Custom Connectors
2. Using OAuth 2.0 in Custom Connectors
3. Unique Redirect URL for OAuth 2.0 Custom Connectors
4. Exported Custom Connector, where’s my client secret setting?
5. The ALM story for Custom Connectors

There is a certification process you can go though in order to get a new connector to be available in the platform among the other connectors. As a connector if you own the API or as an independent publisher connector if not. In some cases that might not be applicable and you want to create the custom connector for a certain project. Then, you want to use Dataverse solutions in order to get healthy ALM for your custom connector.

Custom connector in Solution

Connectors can be created from scratch or you can import a definition from e.g. a Postman collection or Open API definition. If you want to use a custom connector in a production environment you want to build it properly in a development environment first, then try it out in a test environment, before letting the users utilize your automations in production. You will need to use Dataverse solutions.

You can read about custom connectors in solutions in the official documentation. When you create a custom connector in a solution you only get the choice to create it from scratch. You do not want to do that if you have a definition you can use. This is not mentioned (or I missed it) in the official documentation, but you have two different alternatives. In both cases you first create the custom connector outside of a solution, from a definition.

Then either choose to add existing component (custom connector) to your solution. This is mentioned as in Public Preview since March 31, 2022 in a release plan. I can’t find any more information in the official documentation (like GA or not) so make sure you test your custom connector properly. You will not get to choose your own prefix for the custom connector this way though.

The other way would (also) be to create the connector, from a definition, outside of the environment. Then, in your solution, create a connector from scratch. Then open the one created outside of the solution in Swagger mode. Copy from there and paste into swagger mode in your custom connector created in your solution.

Environment variables in custom connectors

It is recommended to have unmanaged solutions in development environments and managed in the other environments (such as test and production). You are not supposed to do any updates in the target environments, except for setting values for environment variables.

In some cases you will need to use environment variables for your custom connector. E.g. if you use OAuth 2.0. In order to be able to successfully export a solution containing a custom connector, you will need to have the client secret in an environment variable.

Otherwise, the client secret setting in the connector will not be included in the exported file. That would result in the custom connector not having a value or something pointing out the value to the client secret. That would result in you being frustrated because of the fact that you cannot create connections successfully until you *not recommended* manually update the client secret field of the connector in the target environment.

Remember to remove the current value of the environment variable before exporting the solution from the development environment. Export as managed (recommended to use umanaged solutions only in the development environment). If you import the solution manually, you will be prompted to add the values to be used in the target environments for the environment variables. You can change the values in an unmanaged solution (or the default solution) later.

Read more: Use environment variables in solution custom connectors.

Cloud flows and connection references

Other things to consider are where to put your cloud flows if you want to create cloud flows that utilizes your connector. There is a known limitation that a custom connector needs to be imported to a target environment prior to importing cloud flows and connection references.

So you will need two different solutions, one for the custom connector and one containing the cloud flows and connection references. (Usually the recommendation is to have one unmanaged solution per development environment, consider this an exception 😏).

I’ve noticed that in some cases the custom connector are added to the solution in which the cloud flows and connection references are located. I’m not sure if this is a bug or intended behavior. I then usually remove it from there. Why have it in two solutions?

Findings

• When working with Custom Connectors in Solutions you do not get the choice to create from a definition/Postman collection. Create it outside of the solution from definition or Postman collection and choose add existing to get it into your solution or copy paste in swagger mode in the custom connector designer.
• You cannot use the client secret directly as is in the custom connector client secret field under Security settings, you need to use environment variables in order to get the client secret setting included in the exported file.
• You can’t have the custom connector and the cloud flows and connection references in the same solution.
• Interesting post on the Power Automate blog: Easier deployments of Custom Connectors. It lists some limitations in the end, I do not know the status of those now.

Also see the landing page for Power Platform and Azure Logic Apps connectors.

Photo by Chris Lawton on Unsplash