I previously shared this Copilot Studio Governance article where I explain that I did not find any suitable and out-of-the-box-solution to programmatically delete Copilot Studio Bots as Admin. For us, responsible for the Power Platform Governance, this is a challenge. We need a method to be able to delete chatbots as admins, the same way as we need it for Power Apps Apps and Power Automate Flows. The Power Platform Admin connectors do offer this option for Apps and Flows, but not for Chatbots. And if it does not exist out-of-the-box, let’s create our own solution for it! And then… Let’s share it here 🎁

• Two main options to delete Copilot Studio Bots as Admins
• The perfect scenario for the Application Users Generator
• The Chatbot Remover Solution
• Comments and Perspectives

Two main options to delete Copilot Studio Bots as Admins

I already presented these options here in more details, but let’s briefly review them below:

• The Dataverse connector Bound Action “PvaDeleteBot”. This action is available from Power Automate, however it does not delete the associated Azure Application. We could add additional actions afterwards to be able to delete the Associated Azure App, but this would require privileges on Azure as well.
• The Dataverse Web API. Using the Dataverse Web API and calling the “PvaDeleteBot” action, it is possible to include the URL Parameter “tag=deprovisionbotondelete” which then also deletes the associated Azure Application. This is what we need, although it is worth mentioning that ⚠️this does not seem to be a supported scenario by Microsoft, since the only documentation I found about this indicates “For internal use only”.⚠️

So although Microsoft does not appear to support it, the Dataverse API approach seems to be the most suitable solution to programmatically delete Chatbots as admins. We need to call this POST request:

https://{OrgApiUrl}/api/data/v9.2/bots({BotId})/Microsoft.Dynamics.CRM.PvaDeleteBot?tag=deprovisionbotondelete

The perfect scenario for the Application Users Generator

Although the Dataverse API approach technically works, it still presents a specific challenge:

• Calling the Dataverse API on an environment requires an Application User on that environment with an appropriate security role
• Some large (or active) organizations might work with hundred of environments. As Power Platform admins, this can be a lot of Application Users to create / manage in order to be able to delete chatbot as admin if and when necessary. Either the admins will need to register such App Users on each environment manually, or they will need a method to automatically generate them on demand just so that they can delete the chatbots.

This is where the Application Users Generator comes in! This solution contains two child flows which allow to create or enable an Application User on an environment and assign it a security role. We will then be able to call the Dataverse API to delete the bot. Finally, the other child Flow of the solution will disable the Application User.

The Chatbot Remover Solution

To make things even easier, I created another solution, the Chatbot Remover, which leverages the App Users Generator to create a Child Flow. This Child Flow allows to delete a bot simply by indicating the botId, environmentId and tenantId. Power Platform Admins can use this child flow in their governance processes and delete bots whenever appropriate.

Let’s explore the structure of this Child Flow.

Overview

1. The Flow takes 3 input parameters for the botId, environmentId and tenantId
2. It then calls the first child flow of the App Users Generator to create the Application User
3. Once the user is generated or enabled we are able to make the HTTP call to delete the bot
4. Finally the other child flow is called to disable the App User

The First Child Flow

We need the first child flow to create the Application User and assign it the System Administrator role for the deletion of the chatbot.

The API Call to delete the bot

Once we have generated the App User, we can get the Azure App secret to authenticate with the Dataverse API (see the App Users Article for more information about accessing the App Secret with the environment variable). This is then time to make the HTTP call to delete the bot.

The second child flow to disable the App User

The Flow then calls the second child flows to disable the App User for security reasons. This flow is always called, even when the HTTP request has failed, to avoid keeping an Application User with elevated privileges on the environment.

Error handling

3 properties are returned to the parent flow:

• Result: “Successful” or “Failed”
• Flow Run Url: to help troubleshooting
• Status Code: the status code of the HTTP request to delete the chatbot. This can help to define the appropriate measures in the parent flow in case of failures.

Comments and Perspectives

A few comments about this solution:

• The App User Generator and the Chatbot Remover solutions have to be in the same environment.
• This environment should be highly restricted, I would advise to only install these solutions on an environment dedicated for the Tenant Admins / CoE. Anyone with access to these child flows will be able to gain elevated permissions.
• One inconvenient of this solution is the absence of logging by design. Unless implemented separately when the child flows are called, there is no track or logs when a chatbot is deleted, or when an Application User is created/disabled.
• An alternative approach could be to use some Dataverse tables to trigger these flows instead of having them as child flows. This would allow to have some logging by default. It would also give more flexibility for access management by leveraging security roles to define who should be able to trigger such processes. Controlling access to the table would control access to these processes. For example:
  • A table “App Users Operations” could be created. Whenever a row would be added to this table, the flow to create or disable the App User would be triggered.
  • A table “Chatbot Deletions” could be created, when a row would be added to this table the flow to delete the bot would be triggered.
• The tenantId parameter for the chatbot remover child flow should not be necessary. We could get the tenantId automatically by using the Graph API for example. I preferred not to to avoid using an additional connector in the solution, and I did not find how to use the Power Platform for Admins connector to get the tenantId in a way which would work for all environments. So I opted for leaving it as an input parameter. Organizations might want to create or use an existing environment variable with the tenantId and update the flow accordingly.