It is sometimes necessary to use the Dataverse API to perform operations on an environment. It can be necessary when integrating with other third party applications, or even from within the Power Platform itself when the out of the box Dataverse connector does not fulfill a specific need. In any case, to use the API, an active Application User will have to exist on that environment. This Application User is necessary to use OAuth authentication and perform the operation. From a governance point of view, keeping active Application Users (usually with high privileges) in environments is not ideal. Now… How great would it be to automatically generate such App Users Just In Time to perform the operation? That sounds like a job for our App Users Generator 😁

• Solution Overview
• Possible Use Cases
• Comments and Ideas

Solution Overview

As usual, the solution is available on my GitHub repository.

The overall idea is to call a first child flows prior to calling the Dataverse Web API. This first child flow creates or enables the Application user on the environment and assigns it the required security role for the operation. It is then possible to call the Dataverse Web API to perform the relevant operations on the environment. Finally, after making this HTTP call, another child flow can disable the Application User for security reasons. For the overall solution to work it requires:

• An App registered in Azure,
• Azure Key Vault to keep the App secret secured,
• The Environment Variables related to the Azure App to be properly configured,
• The two child flows to enable and disable the Application user,
• The actual system which will perform the Dataverse API Call – it can be a Flow or a third party application. I included a Demo flow in the solution as an example.

The App Registration

The App Users Generator is configured to work with a single App Registration in Azure which will be used to set up the Application Users on the target environments. It means that the same App will be associated to the App Users created on each environment. We could easily adjust it to use different App Registrations in different situations though.

This article is not a detailed tutorial to create the App in Azure which is better explained here, but in a nutshell:

• Open Azure Portal to create an App Registration: App registrations – Microsoft Azure
• Create the App by giving it a name and then add a Web Platform configuration with a dummy redirect URI
• No API Permissions needed (wonder why, how? Have a look at this great blog post from Luise Freese which will explain just exactly why)

Azure Key Vault

Once the App Users is in place, Azure Key Vault can be used to securely store the App Registration secret and access them to make the HTTP call with the Dataverse API, without exposing the secret in the flow definition.

It is possible to create an instance of Azure Key Vault fairly easily in Azure with an subscription. Once created, you will have to generate the secret in the Azure App Registration and then upload the secret into Azure Key Vault.

It is worth mentioning that a few more configuration steps are needed to be able to integrate Key Vault and the Power Platform later on (more detailed information here):

• Register Microsoft.PowerPlatform as a resource provider for the Subscription
• Grant the “Key Vault Secrets User” role to the relevant user and the Dataverse Service Principal

The Environment Variables

There are two environment variables for this solution:

• AppUsersGeneratorClientId: the App Id of the App registration stored as text. This variable is used by the child flows to create, enable or disable the Application user associated to this App. It can also be used to authenticate and make the actual HTTP call using the Dataverse API.
• AppUsersGeneratorSecret: this variable is only used to authenticate and make the HTTP call using the Dataverse API. It is a fairly recent type of Environment Variables which comes very handy to use secret safely in cloud flows. To configure this variable you will have to indicate the subscriptionId of the Key Vault, as well as the name of the resource group key vault and secret. During the import of the solution you will need to set it up with this format:
  /subscriptions/{Subscription ID}/resourceGroups/{Resource Group Name}/providers/Microsoft.KeyVault/vaults/{Key Vault Name}/secrets/{Secret Name}

The child flows

The Solution is pretty simple and mainly contains two Child Flows:

• “AppUsersGenerator Child – Create or Enable App User”: This child flow would be called prior to making the Dataverse API call. It takes two input parameters: the Id of the target environment where the operation should be performed, and the name of the security role required for the operation.
  The flow creates or enables the Application User on the target environment, removes any currently assigned role and assigns it the required role instead.
• “AppUsersGenerator Child – Disable App User”: After making the HTTP request with the Dataverse API, this child flow will be called to disable the Application user on the target environment and remove any assigned security role.

The System Performing the API Call: Demo Flow

This flow is not necessary for the solution, but I provide it as a demo to show how the two child flows can be used. This Flow takes an Environment Id and the name of the required security role as Input Parameters and makes an HTTP call with the Dataverse API on that environment.

This is typically how this would be done:

1. Start by calling the Child Flow to Enable or Create the App Users on a target environment by providing the Environment Id and Required Security Role as input parameter
   
2. Leverage the generated / enabled App User and make the HTTP call with the Dataverse API. I am only doing a random GET request here for the demo. We start by getting the App secret thanks to our secret variable and the appropriate Dataverse unbound action, and we can then make the request.
   Note that the outputs of the “Get App Secret” action and the Inputs of the “Example Dataverse API request” action are secured so that the secret is never exposed in the flow execution.
   
3. Finally call the child flow to disable the App User. Running this demo flow shows that making the same HTTP call no longer works after disable the App User used for Authentication.
   

Possible Use Cases

There are two main types of scenarios that I have in mind so far for which this App Users Generator solution will come handy:

• Delete Copilot Studio Bots as admin: as explained in the Copilot Studio Governance article I posted recently, there is not an easy and satisfying way to delete chatbots properly as admins today. The only close-to-satisfying-way I found was to use a non-supported end point with the Dataverse API. Combining the App Users Generator child flows in another child flow which will allow to delete chatbots on any given environment programmatically would be great for governance. I share a solution which does precisely this here.
• Integrate with Third Party Apps: third party web applications can integrate with Dataverse. By calling these child flows before and after, it helps ensure that the App Users does not remain active when not needed.

Comments and Ideas

A few comments about this solution:

• Changing the trigger of the child flows to be executed “when an HTTP request is received” could facilitate integration with third party Apps.
• Access over such Child Flows should be highly restricted. Indeed, if the Tenant Admin connections are used for the child flows, anyone with access over these child flows would be able to generate App users and assign them high privileges on any environment to perform API calls. Would suggest to only install this solution on restricted environments. Proper governance over Environment Access, Connectors, and more is key to ensure this solution can be used safely. I share some key restrictions to consider in this other post.