Environment Specific Custom Connector Endpoints

Phil Cole
Solutions, Custom Connectors

Ever needed to update the endpoint on a custom connector when moving between environments? Find out how to set the endpoint when creating the connection

Consider the following scenario:

  • We’ve created an Azure Function to perform some custom business logic.
  • We’ve got multiple instances of the Azure Function App, one for each of dev, test and production.
  • We’ve created a custom connector to allow the Azure Function to be called by the Power Platform.
  • We’ve added the custom connector to a power platform solution and want to deploy the custom connector into a dev, test and ultimately production environment. For each environment, we want to connect to the appropriate instance of the Azure Function App.

Problem

We now hit an issue. There’s no easy way to update the endpoint on a custom connector. We don’t want to edit the custom connector since that introduces an unmanaged layer, thereby masking any future updates to the custom connector delivered via managed solutions.

Screenshot of Custom Connector General screen

Introducing Custom Connector Policies

Using Custom Connector Policies we can set the custom connector endpoint based on headers or query parameters of the request, or using connection parameters. These are defined using a policy template expression. The example below shows us using a connection parameter.

Custom Connector Policy Definition

“Hang on!” you say, “How do you add parameters to a connector when there’s no user interface within the Custom Connector designer?” There’s information in the Microsoft docs, but it’s a little unclear.

Note: you may prefer to use a URL Template where only part of the URL is parameterised, e.g.

https://<yourapp>-@connectionParamters('envType').azurewebsites.net

Introducing the paconn command line

Custom connector parameters can be created and updated using Microsoft’s ‘paconn’ command-line tool, available on github.

Prior to using this tool we’ll create a custom connector using the make.powerapps.com portal, configure the actions (perhaps by importing an OpenAPI definition) and then assign a custom connector policy (as shown above). We will then:

  1. Download the connector
  2. Alter the connector parameters definition
  3. Upload the connector back into the power platform

Downloading the connector

These steps are documented on the Create and update a custom connector using the CLI docs page, but in summary:

  1. Install python (if you’ve not already done so) and ensure it’s added to the path.

  2. Run pip install paconn to install the paconn tool

  3. paconn login, and authenticate using a device code login process.

    Authenticate with device code login

  4. paconn export. When run, we select the environment and connector interactively.

    Downloading the connector via paconn

Adding the Connection Parameters

We now have a new folder with the connector name, into which the custom connector definition has been downloaded. The downloaded files will be:

  • apiDefinition.swagger.json
  • apiProperties.json <- we need to update this file to add connection parameters
  • icon.png
  • settings.json

Edit apiProperties.json to add in connection parameters.

Before editing:

before editing

After editing (new text highlighted):

after editing

Our custom connector is now ready to be uploaded back into the Power Platform:

paconn update --api-prop .\apiProperties.json --api-def .\apiDefinition.swagger.json

We can now create a new connection for our connector. This time an endpoint is requested.

Testing connector with UAT endpoint

Testing

The quickest way to test a connector is in the connector editor. After selecting a connection, selecting the ‘fact’ action and pressing the ‘Test operation’ button we can see that it failed. However, we expected it to fail because we entered a bogus URL, and that URL is reported in the error message:

Connection failed due to bogus URL

To prove it works we can create another connection and use the correct endpoint URL ‘catfact.ninja’

Connection success

Solution Aware

We can now export the solution and double-check that the connector behaves in the same way in another environment. Exporting and “exploding” the solution into a source control friendly format tells us that the solution still contains the connection parameters in the connection definition.

pac solution clone --name CatFactCustomConnector

We still have the connector parameters:

Connection parameters still in config

After importing the solution (and publishing customisations!) the custom connector is available within a Power Automate Cloud Flow. Upon first use, we’re prompted to create a new connection - and asked for the ‘End point host’ parameter.

Testing connection in new environment

Summary

  • We have a custom connector that accepts a URL parameter for its endpoint.
  • We have deployed a managed solution containing the custom connector that allows an endpoint to be configured for each environment.
  • We have avoided creating an unmanaged layer.

Caution

  • This may not work with OAuth authentication, due to specific application IDs. A topic for a future blog!
  • There is no default value for the URL, if it’s omitted then the API call will fail.

References