Configure the ALM Accelerator manually

You can configure the components of the ALM Accelerator for Power Platform either using the accompanying administration app or manually. This article guides you through configuring the app manually and is structured in seven sections:

• Prerequisites
• Foundational setup
• Development project setup
• Solution setup
• Import the solution and configure the app
• Set up makers to use the ALM Accelerator app

Prerequisites

Before you install the ALM Accelerator for Power Platform, make sure you've met the following prerequisites.

• The ALM Accelerator must be installed in a Power Platform environment that has a Microsoft Dataverse database. All the environments you use the ALM Accelerator to deploy solutions to also require a Dataverse database.

  Note

  The ALM Accelerator isn't compatible with Dataverse for Teams. Both the ALM Accelerator app and the associated pipelines assume that you're using the full version of Dataverse in all environments.

  We recommend you install the ALM Accelerator in the same environment as other CoE Starter Kit solutions. Learn more about how to determine the best strategy for your organization:

  • Establishing an environment strategy for Microsoft Power Platform
  • Environment strategy for ALM

• The ALM Accelerator uses Azure DevOps for source control and deployments. If you don't have an Azure DevOps organization, sign up for free for up to five users on the Azure DevOps site.

• To complete the steps in this section, you need the following users and permissions in Azure, Azure DevOps, and Power Platform:

  • A licensed Azure user with permissions to create and view Microsoft Entra groups, create app registrations, and grant admin consent to app registrations in Microsoft Entra ID
  • A licensed Azure DevOps user with permissions to create and manage pipelines, service connections, repos, and extensions
  • A licensed Power Platform user with permissions to create application users and grant them administrative permissions

• The following connectors must be available to be used together in the environment into which the ALM Accelerator is imported:

  • Dataverse (legacy)
  • HTTP
  • Power Apps for Makers
  • HTTP with Microsoft Entra ID (with endpoint access to https://graph.microsoft.com)
  • ALM Accelerator Custom DevOps (this connector is created as part of the accelerator solution import)
  • Office 365 Users
  • HTTP

• Install the Creator Kit in the environment where you install the ALM Accelerator.

Foundational setup

The following steps are general to the functionality of the ALM Accelerator and aren't specific to any project or solution.

Create an app registration in your Microsoft Entra environment

Create an app registration for the ALM Accelerator to grant the app and associated pipelines permissions required to perform operations in Azure DevOps and Power Apps or Dataverse. You only need to do this once.

The following steps show how to create a single app registration with permissions for both Dataverse and Azure DevOps. However, you might want to create separate app registrations to divide responsibilities. You should consider how separate app registrations affect both maintenance and security before you decide on an app registration strategy.

Create the app registration

1. Sign in to the Azure portal.

2. Select Microsoft Entra ID > App registrations.

3. Select + New registration, and then give the registration a name, such as ALMAcceleratorServicePrincipal.

4. Leave all other options at their default values, and select Register.

Add permissions to the app registration

1. In the left side panel, select API permissions.

2. Select + Add a permission.

3. Select Dynamics CRM, and then select Delegated permissions and user_impersonation.

4. Select Add permissions to add the Dynamics CRM API user_impersonation permission to the app registration.

5. Select + Add a permission again.

6. Select the APIs my organization uses tab. Search for and select PowerApps-Advisor, and then select Delegated permissions and Analysis.All (admin consent not required).

   This permission is required to run static analysis through the app checker.

7. Select Add permissions to add the PowerApps-Advisor API Analysis.All permission to the app registration.

8. Select + Add a permission again.

9. On either the Microsoft APIs tab or the APIs my organization uses tab, select Azure DevOps, and then select Delegated permissions and user_impersonation.

   This permission is required for connecting to Azure DevOps through the custom connector in the ALM Accelerator app.

10. If you added the Azure DevOps permission from the APIs my organization uses tab, copy the Application (client) ID for use later in this procedure.

    You'll use it as the DevOps Application (client) ID, which is different from the Application (client) ID you'll copy later in this procedure.

    

    If you can't find the Azure DevOps permission on the APIs my organization uses tab, follow these steps to get the DevOps Application (client) ID:

    1. Open a private browser window and go to https://dev.azure.com/<your devops organization>/_apis.
    2. On the sign-in page, copy the value of the client_id parameter in the URL.

    

11. Select Add permissions to add the Azure DevOps API user_impersonation permission to the app registration.

12. Select Grant admin consent for <your tenant>.

Configure the client secret and redirect URI

1. In the left side panel, select Certificates & secrets.

2. Select + New client secret.

3. Select an expiration date, and then select Add.

4. Copy the client secret Value for use later. This is the only time you can copy the value. Be sure to do so before you leave the page.

5. In the left side panel, select Overview.

6. Copy the Application (client) ID and Directory (tenant) ID.

7. Select Configure.

Give Power App Management permission to your app registration

Grant Power App Management permissions to your app registration so that the pipelines can perform the actions they need to in your environments. To do that, run the following PowerShell cmdlet as an interactive user that has Power Apps administrative privileges. You only need to run this command once, after you create your app registration.

Important

The following PowerShell cmdlet gives the app registration elevated permissions like Power Platform Admin. Your organization's security policies may not allow these types of permissions. Make sure they're allowed before you continue. If they aren't allowed, certain capabilities don't work in the ALM Accelerator pipelines.

Install-Module -Name Microsoft.PowerApps.Administration.PowerShell
Install-Module -Name Microsoft.PowerApps.PowerShell -AllowClobber
New-PowerAppManagementApp -ApplicationId <the Application (client) ID you copied when you created the app registration>

Install Azure DevOps extensions

The ALM Accelerator uses several Azure DevOps extensions, including some third-party extensions that are available in the Azure DevOps marketplace. The website of each third-party extension and a link to their source code are provided in the following instructions. Learn how to evaluate a Marketplace extension publisher.

1. Sign in to Azure DevOps.

2. Select Organization settings.

3. Select General > Extensions.

4. Search for and install the following extensions:

   • Power Platform Build Tools (required): This extension contains the Microsoft build tasks for Power Platform. (https://marketplace.visualstudio.com/items?itemName=microsoft-IsvExpTools.PowerPlatform-BuildTools)

   • Replace Tokens (required): The pipelines use this extension to replace tokens in configuration files and store secure values in private variables configured for a pipeline. (https://marketplace.visualstudio.com/items?itemName=qetza.replacetokens | https://github.com/qetza/vsts-replacetokens-task)

   • SARIF SAST Scans Tab (optional): Use this extension to visualize the SARIF files the solution checker generates during a build. (SARIF SAST Scans Tab - Visual Studio Marketplace)

     

Clone the YAML pipelines from GitHub to your Azure DevOps instance

1. Go to https://aka.ms/coe-alm-accelerator-templates-latest-release and copy the URL of the most recent release.

2. Sign in to Azure DevOps.

3. Create a project or select an existing project.

4. Select Repos, and then select Import repository in the repository list.

5. Paste the URL you copied in step 1 as the Clone URL, and then select Import.

6. Confirm the default branch for the repo is main. Select Repos and Branches and make sure the main branch is tagged as the default.

   If it isn't, select the three vertical dots (⋮) corresponding to the main branch, and from the More options menu, select Set as default branch.

   Note

   This repo is where the solution pipeline templates and the export/import pipelines run. Later, when you create the pipelines for your solutions, you might need to refer to this specific project and repo if you choose to use a different repo for source control for your solutions.

Create pipelines for import, delete, and export of solutions

Create import, delete, and export pipelines based on the YAML in the Azure DevOps repo. These pipelines run when you use the app to commit a solution to Git, import a solution, or delete a solution.

Note

If you expect all your exports to perform the same actions regardless of the solution for which the pipeline is running, you can create a single export pipeline as described in this section. However, you might need different export actions based on the solution. In that case, you can append the solution name to the export-solution-to-git pipeline, like export-solution-to-git-SampleSolution, to have the app execute your specific solution pipelines when you perform the actions in the app.

The following table shows the correspondence between the YAML file in the repo and its accompanying pipeline.

YAML file	Pipeline name
export-solution-to-git.yml	export-solution-to-git
import-unmanaged-to-dev-environment.yml	import-unmanaged-to-dev-environment
delete-unmanaged-solution-and-components.yml	delete-unmanaged-solution-and-components

1. In Azure DevOps, go to Pipelines > Create a New Pipeline.

2. Select Azure Repos Git for your code repository, and then point to the Azure DevOps repo you created and seeded with the pipeline templates in the earlier steps.

3. On the Configure your pipeline page, select Existing Azure Pipelines YAML file and point to /Pipelines/export-solution-to-git.yml, /Pipelines/import-unmanaged-to-dev-environment.yml or /Pipelines/delete-unmanaged-solution-and-components.yml.

4. Select Continue, and then select Save.

5. Select the More menu (…) next to Run Pipeline, and then select Rename/Move.

6. Change the pipeline name to export-solution-to-git, import-unmanaged-to-dev-environment, or delete-unmanaged-solution-and-components, as appropriate.

7. Select Save.

Create export pipeline variables (optional)

You may set pipeline variables on the export-solution-to-git pipeline to control what information is persisted to source control. To apply these settings globally, set the variables on your export-solution-to-git pipeline. To apply the settings to specific solutions on export, create an export pipeline for your solution as described in the note in the previous section, and set the variables on that pipeline.

To make sure the current values of environment variables are never committed to source control during the export process, create the DoNotExportCurrentEnvironmentVariableValues variable on your export-solution-to-git pipeline and set its value to True.

Important

This pipeline variable is recommended so that you can use the deployment configuration functionality in the ALM Accelerator.

To make sure the values of specific default environment variables are set during the export of a solution, create the VerifyDefaultEnvironmentVariableValues variable on your export-solution-to-git pipeline and set its value to True. Set the values of default environment variables in the customDeploymentSettings.json as described in the deployment configuration guide.

1. In Azure DevOps, select Pipelines > Library > Create a new Variable Group.

2. Name the new variable group alm-accelerator-variable-group, exactly as given here.

   The pipelines refer to this specific variable group, so it must be named exactly as shown. If you decide to use a different naming convention for your variable group, you need to modify parts of the pipelines to refer to the name you use instead.

3. Add the following variables to the variable group:

   Name	Description	Value
   AADHost	The Microsoft Entra authorization endpoint	For public clouds, use login.microsoftonline.com. For government clouds, use the appropriate authorization URL.
   ProcessCanvasApps	Whether canvas apps are unpacked during export or packed during builds	If False, then the canvas apps aren't unpacked during export or packed during builds. The canvas app unpack and pack functionality is in preview and isn't recommended for use in production environments at this time. However, you can't view canvas source code in source control unless you set this variable to True.

4. (Optional) If you use canvas studio test automation in your pipelines, add the following variables to the variable group:

   Name	Value
   TestAutomationLoginMethod	CloudIdentity
   TestAutomationMakerPortalUrl	The URL from the Power Apps maker portal, typically *https://make.powerapps.com*
   TestAutomationUsername	The user account used to execute the automated tests
   TestAutomationPassword	The password for the user account used to execute the automated tests

5. (Optional) By default, the global variables are restricted and you need to configure access for each pipeline. You can simplify that and allow access for any pipeline. Under the Variable group (Pipelines > Library > alm-accelerator-variable-group), select Pipeline permissions in the top menu, select (…), and then select Open access.

Set permissions for the project build service

Important

Azure DevOps contains a number of "Build Service" accounts, and it might be confusing as you follow the steps in this section. Pay close attention to the names and format specified in steps 3 and 5. You might need to search for the specific account if it doesn't show up in the initial list.

1. In Azure DevOps, select Project settings.

2. Select Repositories > Security.

3. Under Users, search for and select Project Collection Build Service (Your Organization Name).

   Note

   You might not see Your Organization Name after the Project Collection Build Service user. It may be just a unique identifier. In this case, use the search function to find the user, and then select it.

4. Set the following permissions for the build service user:

   Permission	Value
   Contribute	Allow
   Contribute to pull requests	Allow
   Create branch	Allow
   Edit policies	Allow

5. Under Users, search for and select Your Project Name Build Service (Your Organization Name).

6. Set the same values as in step 4.

7. Select Pipelines, select the three dots (…) in the upper-right corner, and then select Manage Security.

8. Set the following permissions for the Your Project Name Build Service (Your Organization Name) user:

   Permission	Value
   Edit build pipeline	Allow
   Edit build quality	Allow
   Manage build queue	Allow
   Override check-in validation by build	Allow
   Update build information	Allow
   View builds pipeline	Allow
   View builds	Allow

9. Select Project settings > Agent pools, select Security, and then select Add.

10. Search for and select Your Project Name Build Service (Your Organization Name).

11. Set the Role to Reader.

12. Select Add.

13. (Optional) By default, the pipeline permissions for each repository are restricted and you need to configure them individually. You can simplify that and allow access for any pipeline. Under Project Settings > Repositories, select each repository in turn. Select Security in the top menu. Find the Pipeline permissions block, select (…), and then select Open access.

Development project setup

The following section guides you through the steps required to set up each of the development projects you support. In this context, a development project comprises the infrastructure and configuration that supports healthy application lifecycle management (ALM), including the configuration of the Dataverse environment that supports the ALM process itself.

Create service connections for Azure DevOps to access Power Platform

Each Dataverse environment—development, validation, test, and production—must have a Power Platform service connection in Azure DevOps. Perform the following steps for each of your environments.

Note

ALM Accelerator app users see only environments in which they have either a user or administrator role on the service connection in Azure DevOps. If they work in personal development environments, makers must have a user or administrator role on the service connection for their personal development environment. Validation, test, and production environment service connections like the build service only need permissions granted to pipelines.

1. Sign in to Azure DevOps, and then select your project.

2. Select Project settings > Service connections, and then select Create service connection.

3. Search for and select the Power Platform service connection type.

4. Select Next.

5. For Server URL, enter your environment URL; for example, https://myorg.crm.dynamics.com/.

   Important

   You must include the trailing forward slash (/) in the URL; that is, after .com in this example.

6. For Service Connection Name, enter the same URL you entered in step 4, including the training forward slash (/).

7. Enter the Tenant ID, Application (client) ID, and Client Secret you copied from Microsoft Entra when you created the app registration.

8. Select Grant access permissions to all pipelines.

9. Select Save.

The service connections must provide user permissions to all users in all environments that users need to be able to access from the app (for example, maker environments).

1. In the Service Connections list, select the service connection to be shared with users.

2. Select More (…) in the upper-right corner, and then select Security.

3. In the Group or User list, select the user or group you want to provide user permissions to.

4. Select the User, select a Role, and then select Add.

Repeat the steps in this section for each of your development, validation, test, and production environments.

Set permissions for the project build service to use the service connections

1. In Azure DevOps, select Project settings > Service connections.

2. Select (…) in the upper-right corner, select Security, and then select Add.

3. Search for and select Your Project Name Build Service (Your Organization Name).

4. Set the Role to Administrator, and then select Add.

Create an app user in your Dataverse environments

Create an application user in your environments to allow the pipelines to connect to Dataverse. Do this in each environment you plan to use the ALM Accelerator to deploy to.

1. Sign in to the Power Platform admin center.

2. Select your development environment, and then select Settings.

3. Select Users + permissions > Application users.

4. Select + New app user.

5. Select + Add an app, select the app registration you created earlier, and then select Add.

6. Select the Business Unit.

7. Select the pencil icon to the right of Security roles, and then select security roles for the app user.

   We recommend you give the app user system administrator security role privileges, so the user can perform the required functions in each environment.

8. Select Create.

Repeat these steps in your validation, test, and production environments.

Solution setup

When you create a solution in Dataverse, you need to create pipelines specifically for that solution. The following sample pipelines are included in the Pipelines directory in the coe-alm-templates repository:

• https://github.com/microsoft/coe-alm-accelerator-templates/blob/main/Pipelines/build-deploy-validation-SampleSolution.yml
• https://github.com/microsoft/coe-alm-accelerator-templates/blob/main/Pipelines/build-deploy-test-SampleSolution.yml
• https://github.com/microsoft/coe-alm-accelerator-templates/blob/main/Pipelines/build-deploy-prod-SampleSolution.yml

The sample pipelines provide flexibility for organizations to store their pipeline templates in a separate project or repo from the specific solution pipeline YAML. Follow the steps in this section to configure your solution pipeline. Repeat these steps for each solution for which you're using the ALM Accelerator for source control.

Important

The YAML for your solution pipeline is always stored in the same repo you use for source control for your solution. However, the pipeline templates—that is, the folder Pipeline\Templates—can exist either in the same repo as your solution pipeline YAML or in a separate repo or project.

Create the solution build and deployment pipelines

Solution pipelines are used to build and deploy your source-controlled solutions to environments in your tenant. The sample pipelines assume you're using only three environments: validation, test, and production. However, you can create as many solution pipelines as needed based on your organization's environment strategy.

The sample deployment pipelines are triggered by changes to a branch (that is, test and production) or as a part of a branch policy in Azure DevOps (that is, validation). Learn more about setting branch policies for pull request validation. You can also run pipelines manually, without a trigger.

Follow the steps in this section to create deployment pipelines from the sample pipeline YAML. The following table describes the pipeline configuration.

Important

The pipeline name must be exactly as shown in the following table, with the name of your solution in place of MyNewSolution.

Pipeline YAML file name	Pipeline name	Branch policy enabled	Required
build-deploy-validation-MyNewSolution.yml	deploy-validation-MyNewSolution	Yes	Yes
build-deploy-test-MyNewSolution.yml	deploy-test-MyNewSolution	No	Yes
build-deploy-prod-MyNewSolution.yml	deploy-prod-MyNewSolution	No	No (Go to the next section)

Note

The following steps create build and deploy pipelines for the validation, test, and production environments. However, you might want to build and deploy to validation and test and then deploy the artifacts from the test build to production. If that's the case, follow the steps in this section for only your validation and test environments. Then, skip to Create the solution deployment pipeline to configure your release pipeline.

Create the pipeline file

1. In Azure DevOps, go to the repo that contains the pipelines folder you committed, and select the Pipelines folder.

2. Open one of the three sample deployment pipelines and copy the YAML to use in your new pipeline.

3. Note the name of the repo for use in your pipeline.

4. Go to the repo that you want to use for source control for your solution.

5. Create a branch based on your default branch and name it for your solution; for example, MyNewSolution.

   This branch becomes the next version (v-next) branch for your solution. All development work must be branched from this branch to a developer's personal working branch, and then merged into the v-next branch to push to validation and testing. Later, when a release is ready, the v-next branch can be merged into the main or default branch.

6. Select New from the top menu, and then select Folder.

7. Give the new folder the same name as your solution.

8. Give the new pipeline YAML file a name, such as build-deploy-validation-SampleSolution.yml, build-deploy-test-SampleSolution.yml, or build-deploy-prod-SampleSolution.yml.

9. Select Create.

Update and save the file

1. Paste the YAML you copied in step 2 in the previous section into the new pipeline file.

2. Change the following values in the new pipeline YAML:

   • Change Resources > Repositories > Name to the name of the repo that contains your pipeline templates.

     In this example, the repo is named coe-alm-accelerator-templates and it exists in the same project as the MyNewSolution repo. If your template repository is in a different Azure DevOps project, use the format ProjectName/RepoName. You can also specify a branch for where your templates live using the ref parameter if necessary.

   • Change any value that refers to SampleSolutionName to the unique name of your solution; for example, MyNewSolution.

3. Select Commit to save your changes.

4. In Azure DevOps, go to Pipelines, and then select Create a New Pipeline.

5. Select Azure Repos Git for your code repository.

6. Select the DevOps repo, which contains the deployment pipeline YAML.

7. On the Configure your pipeline page, select Existing Azure Pipelines YAML file, point to the YAML file in your repo that you created earlier, and then select Continue.

8. Select Save, select (…) next to Run Pipeline, and then select Rename/Move.

9. Change the pipeline name to deploy-validation-MyNewSolution, deploy-test-MyNewSolution, or deploy-prod-MyNewSolution, where MyNewSolution is the name of your solution.

10. Select Save.

11. If your new pipeline wasn't created in the repository's default branch: Select Edit on the pipeline. Select (…) in the upper-right corner, and then select Triggers. Select the YAML tab, and then select Get Sources. Change the Default branch for manual and scheduled builds to point to your solution branch. Learn more about how to configure pipeline triggers.

12. Repeat the preceding steps to create a deployment pipeline for each of your environments, referencing the sample deployment pipeline YAML from the coe-alm-accelerator-templates repo (deploy-validation-SampleSolution.yml, deploy-test-SampleSolution.yml, and deploy-prod-SampleSolution.yml).

13. Select Save and Queue, and then select Save.

Create the solution deployment pipeline (optional)

As mentioned earlier, the steps in the previous section create pipelines that build and deploy for validation, test, and production environments. However, you can create a separate solution deployment pipeline if you want to build and deploy only for validation and test and then deploy the artifacts from the test build to production.

Follow the steps in this section to create a solution deployment pipeline from the sample pipeline YAML. The following table describes the pipeline configuration.

Important

The pipeline name must be exactly as shown in the following table, with the name of your solution in place of MyNewSolution.

Pipeline YAML file name	Pipeline name	Branch policy enabled
deploy-prod-MyNewSolution.yml	deploy-prod-MyNewSolution	No

1. In Azure DevOps, go to the repo that contains the pipelines folder you committed and select the Pipelines folder.

2. Open the sample deployment pipeline deploy-prod-pipelineartifact-SampleSolution.yml, and copy the YAML to use in your new pipeline.

3. Note the name of the repo for use in your pipeline.

4. Go to the repo that you want to use for source control for your solution.

5. Select New from the top menu, and then select File.

6. Give the new pipeline YAML file a name; for example, deploy-prod-MyNewSolution.yml, where MyNewSolution is the name of your solution.

7. Select Create.

8. Paste the YAML you copied in step 2 into the new pipeline file.

9. Change the following values in the new pipeline YAML:

   • Change Trigger > Branches > Include to the branches in which changes should trigger a deployment to production.

   • Change Resources > Repositories > Name to the name of the repo that contains your pipeline templates.

     In this example, the repo is named coe-alm-accelerator-templates and it exists in the same project as the MyNewSolution repo. If your template repository is in a different Azure DevOps project, use the format ProjectName/RepoName. You can also specify a branch for where your templates live using the ref parameter if necessary.

   • Update Resources > Pipelines > Source to specify the build pipeline that contains the artifacts this pipeline should deploy. In this case, you're going to deploy the artifacts from the test pipeline you created earlier, which built and deployed your solution to the test environment.

   • Change any value that refers to SampleSolutionName to the unique name of your solution; for example, MyNewSolution.

10. Repeat steps 11 through 20 in the previous section for deploy-validation-ALMAcceleratorSampleSolution and deploy-test-ALMAcceleratorSampleSolution, to create a pipeline from the new production pipeline YAML named deploy-prod-ALMAcceleratorSampleSolution.

Set deployment pipeline variables

For each deployment pipeline you configured earlier, you must set the values of the variables EnvironmentName and ServiceConnection based on the environment to which the pipeline deploys. You can also set the EnableFlows variable to turn off Power Automate flows as part of a deployment.

Create environment and service connection variables (required)

Every deployment pipeline requires the environment variable EnvironmentName and the service connection variable ServiceConnection.

• EnvironmentName specifies the Azure DevOps environment that's being deployed to enable tracking deployment history and set permissions and approvals for deployment to specific environments. Set this value to Validate, Test, or Production, as appropriate.

• ServiceConnection specifies how the deployment pipeline connects to Power Platform. Allowed values are the names of the service connections you created earlier.

1. Select Edit on each of the deployment pipelines.

2. Select Variables on the deployment pipeline definition to open the variables editor.

3. To add a variable, select (+). Enter the name of the variable and the appropriate value.

Repeat these steps to create the EnvironmentName and ServiceConnection variables.

Create the EnableFlows variable (optional)

You may set the value of a pipeline variable named EnableFlows to False to skip the steps that automatically enable Power Automate flows as part of a deployment. The default value of the EnableFlows variable is True.

Set branch policies for pull request validation

Create a branch policy to execute the pipeline you created earlier when a pull request is created.

1. In Azure DevOps, go to Repos, and then select the Branches folder.

2. Find the branch for which you want to create the pull request policy. Select (…) to the right of the branch, and then select Branch Policies.

3. On the Branch Policies page, go to Build Validation.

4. Select + to add a new branch policy.

5. In the Build pipeline list, select the pipeline you created earlier.

6. Specify a Path filter if applicable to make sure that only changes to the specified path trigger the pipeline for the pull request.

7. Set the Trigger to Automatic.

8. Set the Policy requirement to Required.

9. Set the Build expiration to Immediately.

10. Set a Display name for your branch policy; for example, PR Build Validation.

11. Select Save.

Set resource access permissions for pipelines

Pipelines need access to required resources, such as repositories, variable groups, and service connections, to run. To allow access, you have three options.

Grant access during the first run

You can allow access to a required resource during the pipeline's first run.

1. Trigger the pipeline and open the pipeline run in Azure DevOps.
2. Select View in the "permission required" banner.
3. Select Permit for each required resource.

Give explicit permission

You can give explicit permission for a pipeline to access required repos.

1. In Azure DevOps, open Project settings.
2. Select Repositories, and then select a repository.
3. Select the Security tab.
4. Scroll down to Pipeline permissions and select +.
5. Select the pipeline that you want to give access to the repository.

You can give explicit permission for a pipeline to access required variable groups.

1. In Azure DevOps, select Pipelines > Library, and then select a variable group.
2. Select Pipeline permissions.
3. Select +, and then select the pipeline that you want to give access to the variable group.

You can give explicit permission for a pipeline to access required service connections.

1. In Azure DevOps, open Project settings.
2. Select Service Connections, and then select a service connection.
3. Select More actions (…), and then select Security.
4. Scroll down to Pipeline permissions and select +.
5. Select the pipeline that you want to give access to the service connection.

Grant all pipelines access

You can allow all pipelines, both the ones you have now and any you create in the future, to access required repositories.

1. In Azure DevOps, open Project settings.
2. Select Repositories, and then select a repository.
3. Select the Security tab.
4. Scroll down to Pipeline permissions.
5. Select More actions (…), select Open access, and then confirm when prompted.

You can allow all pipelines to access required variable groups.

1. In Azure DevOps, select Pipelines > Library, and then select a variable group.
2. Select Pipeline permissions.
3. Select More actions (…), select Open access, and then confirm when prompted.

You can allow all pipelines to access required service connections.

1. In Azure DevOps, open Project settings.
2. Select Service Connections, and then select a service connection.
3. Select More actions (…), and then select Security.
4. Select a service connection, select the More actions (…), and then select Security.
5. Scroll down to Pipeline permissions.
6. Select More actions (…), select Open access, and then confirm when prompted.

Set Job authorization scope

Job authorization scope can be set for the entire Azure DevOps organization or for a specific project. Disable the Limit job authorization scope to current project for release pipelines setting, if you choose a different Azure DevOps project to install the templates.

To set job authorization scope at the organization level for all projects

1. In Azure DevOps,choose Organization settings > Pipelines > Settings.
2. Disable the Limit job authorization scope to current project for release pipelines setting.

Create a deployment configuration (optional)

You need to create several configurations in a target environment after a solution is deployed. These configurations are specific to the environment and include connection references, environment variables, and permissions for Microsoft Entra groups and Dataverse teams, in addition to sharing canvas apps and updating the ownership of solution components such as Power Automate flows. Along with these configurations, a target environment often needs sample or configuration data that's associated with Dataverse tables in the solution to provide a full end-to-end ALM experience.

If your solution requires these other configurations or data, follow the deployment configuration guide to configure your pipelines based on the environments to which you're deploying.

Import the solution and configure the app

Import the ALM Accelerator canvas app into your Power Platform environment, and then configure the included custom connector for Azure DevOps.

Install the ALM Accelerator in Dataverse

1. The ALM Accelerator solution depends on the Creator Kit. Install the Creator Kit now.

2. Download the latest managed solution file from GitHub. Scroll down to Assets and select CenterofExcellenceALMAccelerator_<latest version>_managed.zip.

3. Sign in to Power Apps, and then select the environment you want to host the ALM Accelerator app.

4. In the left side panel, select Solutions.

5. Select Import solution > Browse, and then browse to the location of the managed solution you downloaded and select the file.

6. Select Next, and then select Next again.

7. On the Connections page, select or create a connection to connect the CDS DevOps connection to Dataverse.

   When you create a connection for HTTP with Microsoft Entra, use Microsoft Graph for both parameters.

8. Select Import.

Configure the DevOps custom connector

1. Select Data > Custom Connectors > CustomAzureDevOps.

2. Select Edit. On the Security page, select Edit, and then set the following fields:

   Name	Value
   Authentication Type	OAuth 2.0
   Identity provider	Azure Active Directory
   Client ID	The Application (client) ID you copied when you created the app registration
   Client secret	The Application (client) secret value you copied when you created the app registration
   Tenant ID	Leave the default value, common
   Resource URL	The DevOps Application (client) ID you copied when you added permissions to your app registration
   Redirect URL	Autogenerates. If you notice the 'Update to unique redirect URL' checkbox below the 'Redirect URL,' please check the checkbox.

3. Select Update connector.

Add the 'Redirect URL' as 'Redirect URI'

The autogenerated 'Redirect URL' from the above section needs to be added as the 'Redirect URI' to the app registration.

1. Return to the app registration you created.

2. In the left side panel, select Overview.

3. Select Add a Redirect URI.

4. Select + Add a Platform, and then select Web.

5. Under the Redirect URIs textbox, paste the autogenerated 'Redirect URL' copied from the above section.

6. Select Configure.

Test the custom connector

1. Open the Test menu.

2. Select New Connection, and then follow the prompts to create a connection.

3. In Power Apps, select your environment, and then select Dataverse > Custom Connectors > CustomAzureDevOps.

4. Select Edit, go to the Test page, and then find the GetOrganizations operation.

5. Select Test operation.

6. Confirm the Response Status returned is 200 and that the Response Body is a JSON representation of your Azure DevOps organization.

   

Set up makers to use the ALM Accelerator app

• Configure user permissions for a maker's account in Dataverse and Azure DevOps.

• Configure deployment user settings to set up the app's user experience and grant access to solutions and deployment profiles.

Read more

• ALM Accelerator for Power Platform
• Configure deployment profiles
• Configuration and data deployment in pipelines
• Configuration and data deployment in pipelines
• Configure pipeline sync