How to share a custom connector with PowerShell

There are currently more than 800 connectors available for Power Automate and Power Apps that allow us to interact with other web services.

However, despite this wide choice there may be a need to interface with custom services for which there is no default connector.

In such cases, custom connectors make it possible to create connectors for any Web service that has a REST API.

Among the various activities involved in creating and configuring a custom connector is sharing it with a user or group.

Sharing a custom connector is a basic operation.

However, there is one small detail that makes this simple activity slightly more arduous.

This is the sharing of a custom connector within a solution.

In this article, we will focus on this issue.

I will show you how you can get around the current sharing problem by exploiting PowerShell.

I will show you the basic commands for creating, retriving information and removing the sharing of a custom connector with a User or Group.

At the end of this article I will also reveal a second method of resolution based on modifying the Dataverse ‘Connector’ table.

Before delving into the concrete, let’s try to imagine a simple scenario.

Imagine you have to develop Power Apps Canvas to mange an inventory.

You will have to provide automatic processes for notifying and updating data.

You will also need to interface with third-party services.


Therefore, in order to build custom REST APIs, you need to create a custom connector that will be used in your components.

To facilitate the life cycle of your application you create a solution where you insert the components you have developed and the custom connector. 

Adding a custom connector to a solution will help you a lot when releasing changes and managing the connections used in your components.

However, if you add the custom connector to a solution, the sharing functionality is disabled.

At this point, you might ask yourself: “Why not leave the custom connector out of the solution?

Mainly because this decision may complicate porting, the creation of future connections and you may add unwanted errors by updating the swagger directly.

Reasons that cannot be overlooked.

We must therefore be able to share a custom connector with a user even if it is inside a solution.

NOTA: I recommend that you place all custom connectors in a separate solution and import that solution into the target environment before the other changes.

Now that we have defined a possible scenario and indicated possible complications, let us see what has been said.

Let us start with classic sharing and then shift our attention to the solution case with custom connector. 

For this occasion, I have taken advantage of the API made available by the .

In order to consume these APIs, it will not be necessary to go and configure the security tab as they are fake data accessible to everyone.

As you can see in the image below, I created a custom connector called “ReqResAPI” out of any solution.


In this scenario, to share the custom connector with a user, you will need to click on the 3 dots and then click on share.

As you can see by accessing the share section, you can simply add new users by giving them a role.


Surely if you have already worked with custom connectors, these steps will be basic.

Let us now set up the Solution with custom connector scenario.

I have created a solution called “OnlyCustomConnector” and inserted a new custom connector inside it called “InsideSolution“, see the image below.


At this point, if you try to add a user in the classic way, you will notice that the save button is disabled.

This is a major inconvenience, because if you are unable to share the custom connector with a user or group, you will not be able to create the necessary connections for your application.

It is therefore necessary to find a way around this problem.

In the next few lines I will show you how to use PowerShell to solve this problem, but first there are a couple of preliminary tasks to do.

If this is your first time interfacing with PowerApps via PowerShell, you will need to install a couple of modules.

Run PowerShell as administrator.

Next, launch the commands below:

Install-Module -Name Microsoft.PowerApps.Administration.PowerShell
Install-Module -Name Microsoft.PowerApps.PowerShell -AllowClobber

The commands I have given you are sufficient to set up the environment, but if you want to go deeper, you can consult the documentation I have provided here.

Now that the modules have been installed, you need to retrieve some information that will come in handy later.

You will need to know:

User ObjectID, the same applies in case you want to share with a group registered in Azure Active Directory (AAD)

Environment ID

Custom connector’s logic name

Let’s start with ObjectID.  

First, go to Azure and in the Active Directory search for the user concerned.

As you can see in the image below, it is very easy to obtain the Object ID

To retrieve the Environment Id and the logical name of the custom connector you can do this in one go.

Simply re-open the Custom Connector in edit mode and all the information will be reflected in the URL.

For example:


In my case the string “Default-1092 …” indicates the Environment ID while the string “shared_new-5finside…” indicates the logical name of the custom connector.

If you are not sure of the value of the Environment ID, you can proceed via the administrator interface.

After selecting the environment in which you are working, you will find the environment information in the details section.


Great we got all the information we needed.

We can finally proceed to share the custom connector with PowerShell.

To do this, use the following command:

Set-AdminPowerAppConnectorRoleAssignment -ConnectorName [Connector_Logic_Name] -EnvironmentName [Environment_ID] -RoleName [Role_Name_Value] -PrincipalType [Principal_Type_Value] -PrincipalObjectId [Principal_Guid]

To consult the documentation page you can click here .

What you need to do at this point is to substitute the parameters in the command:

  • [Connector_Logic_Name]: replace with the logical name of the custom connector obtained earlier.
  • [Environment_ID]: replace with the previously obtained customised connector’s logical name.
  • [Role_Name_Value]: this parameter indicates the permission level to be given to the connection.  Valid options are CanView, CanViewWithShare,CanEdit.
  • [Principal_Type_Value]: this parameter indicates the type of entity which the custom connector will be shared. The options are User, Group, or the entire Tenat
  • [Principal_Object_Guid]: replace with the Object ID of the entity obtained earlier.

Great, you can now run the command directly in PowerShell.

If this is the first time you run it, you will be asked to log in.

As you can see in the picture here on the right, if everything went well, you will receive a response with code 200.


To show you the difference between the RoleName parameter I also added my user with edit permission (CanEdit). 

You can now verify that the user has indeed been added correctly. Go back to the sharing section of the Custom Connector and in the list “currently shared with..” you will find the user you have added.

Now that you have managed to share the custom connector with a user, you can try to retrive the user-related information using PowerShell.

To do this, simply run the following command

Get-AdminPowerAppConnectorRoleAssignment -ConnectorName [Connector_Logic_Name] -EnvironmentName [Environment_ID] -PrincipalObjectId [Principal_Guid]

For more details on the parameters of this command, see here.

You can also use this command to verify that the write operation was successful. 

Above all, this command will come in handy if you want to go and remove the user to whom you have shared the custom connector.

In fact, by executing the Get command you will find in the response the RoleId, containing the RoleName, i.e. the guid of the previously created permission.


Using this information you can construct your own command to remove the sharing permission, see here for more details. 

Remove-AdminPowerAppConnectorRoleAssignment -EnvironmentName [Environment_ID] -ConnectorName [Connector_Logic_Name] -RoleId /providers/Microsoft.PowerApps/scopes/admin/environments/[Guid]/apis/shared_testapi.[Guid]/permissions/[Guid]

These are the main commands you need to use in order to share a custom connector in a solution via PowerShell.

But you don’t necessarily have to limit yourself to one user. 

Imagine in fact that you have a group censored in Azure Activity Directory (AAD). 

You can share the custom connector directly to the group. 

Again, you will first have to retrieve the Object ID, but then the commands will be the same as those we have seen for sharing with a user.

The only change you will have to make is to replace the –PrincipalType parameter which was previously set to User but now you will have to set it to Group. 

To show you this possibility, I created a group called Support-Team.

I retrieved the ObjectId and composed the Set- AdminPowerAppConnectorRoleAssignment command. As you can see in the image below, the custom connector is now also shared with the Support-Team group.

As you could see, thanks to PowerShell we were able to share a custom connector with users and groups in AAD. 

As I told you initially, there is also another way to solve this problem.

This solution involves directly modifying the custom connector record in the Dataverse “Connector” table. 

For this implementation, I share with you a video prepared by the PowerCAT team where Phil Topness illustrates the various steps.

Watch the video here.

In conclusion, we can say that solution-centred Microsoft Power Platform project management is, in my opinion, the perfect mechanism to transport components from one environment to another. 

The most important thing is that I can include all my components such as canvas apps, flows and custom connectors in one coherent package.

This helps to export and import components with all their dependencies.

With the two methods I have given you in this article, you can greatly improve your porting and application lifecycle management.