Create and manage inherited processes
Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019
In Azure DevOps, you have the flexibility to customize your project, Agile tools, and the work tracking system by using inherited processes. These customizations apply to all projects that utilize the same process.
An inherited process serves as the foundation for your work tracking system. When you create a new project, you choose a process to define its building blocks. These building blocks include work item types, states, fields, and rules. By customizing an inherited process, you tailor it to your team’s specific needs.
Important
The Inheritance process model is available for projects configured to support it. If you’re using an older collection, check the process model compatibility. If your on-premises collection is configured to use the on-premises XML process model, you can only use that process model to customize the work tracking experience. For more information, see Choose the process model for your project collection.
For more information about what you can customize, see About process customization and inherited processes.
Note
Review changes made to an inherited process through the audit log. For more information, see Access, export, and filter audit logs.
Prerequisites
For guidance on tailoring Azure Boards to align with your specific business requirements, see About configuring and customizing Azure Boards.
Organization requirement: Ensure you have an organization in Azure DevOps.
Permissions:
- Be a member of the Project Collection Administrators group.
- Have collection-level permissions such as Create process, Delete process, Edit process, or Delete a field from organization set to Allow.
- These permissions allow you to modify processes and fields within your organization.
Project process model requirement:
- Ensure that you have the Inheritance process model for the project collection where the project is created.
Permissions:
- Be a member of the Project Collection Administrators group.
- Have collection-level permissions such as Create process, Delete process, Edit process, or Delete a field from organization set to Allow.
- These permissions allow you to modify processes and fields within your organization.
Create an inherited process
Do the following steps to create an inherited process that you can customize. The default, system processes are locked, so you can't customize them.
Sign in to your organization (
https://dev.azure.com/{yourorganization}).Select
Organization settings.
Select Process > ... (More actions) > Create inherited process. Choose the same system process—Agile, Basic, Scrum, or CMMI—that was used to create the project that you want to customize.
In the following example, we create an inherited process from the Agile system process.
If you don't have access to these options, ask a member of your Project Collection Administrators group to grant you permissions. To find a member, see Look up a Project Collection Administrator.
Enter a name for your process and optionally a description. Process names must be unique and no more than 128 characters. For other restrictions, see Create and manage inheritance processes, Process name restrictions.
Sign in to your collection.
Select Collection settings or Admin settings.
Select Process.
Important
If you don't have the Create inherited process menu option, then the collection you selected is set to work with the on-premises XML process model. For more information, see On-premises XML process model.
Inherited child processes automatically update, based on their parent system processes. Updates to processes are documented in Release Notes for Azure DevOps Server.
After you define the inherited process, you can do the following tasks:
- Customize a project using an inherited process
- Create a project that uses the inherited process
- Change project to use the inherited process
Change a project's process
You can change a project’s process from one inherited process to another with the following methods:
- Switch within the same base process: Move a project between processes that share the same base, such as Agile or Scrum.
- Migrate to a different process model: Change the project’s process model, for instance, from Agile to Scrum or Basic to Agile.
We provide detailed steps for the second method, covering the following common scenarios of process change:
Note
- You can change the process of a project as long as you don't have any undeleted work items of a custom work item type that isn't also defined in the target process.
- If you change a project to a system process or other inherited process that doesn't contain the same custom fields, data is still maintained. But, the custom fields that aren't represented in the current process won't appear on the work item form. You can still access the field data through a query or REST APIs. These fields are essentially locked from changes and appear as read-only values.
Select your project's process. For example, to change a project from Agile to Scrum, then choose the Agile process.
Select Projects > the
actions icon for the project > Change process.
Complete the steps in the wizard.
Important
When you switch a project to an inherited process, some Agile tools or work items might become invalid. For example:
- If you designate a field as required, work items lacking that field display an error message. Resolve these errors to proceed with further changes and save the work item.
- When you add or modify workflow states for a WIT visible on your board, remember to update the board column configurations for all teams within the project.
Create a project from a process
Open the … context menu for the process you want to use and select New team project.
Enter your project information, and then select Create. For more information, see Create a project.
Copy a process
Before you implement customizations across your organization, it's essential to test them by doing the following steps.
Tip
If you modify a process used by multiple projects, each project immediately reflects the incremental process change. To bundle process changes before rolling them out to all projects, do the following steps.
From the Process page, open the … context menu for the process and select Create copy of process.
Enter a name and optional description for the copied process and select Copy process.
Make your changes to the copied process. Since no project is using this process, these changes don't affect any projects.
Verify your changes by creating a test project based on the copied and updated process. If you already created a test project, select Change project to use ProcessName.
Roll out your updates by changing the process of the projects that need the new changes. Select Change project to use ProcessName.
Disable or delete the original process.
Enable/disable a process
To prevent projects being created from a specific process, you can disable it. You might choose this option when you want to apply several customizations and don't want the process used until they're complete. Or, you might retire use of a specific process in favor of moving projects to a new process.
All system processes and newly created inherited processes are enabled by default. To disable or enable a process, open the … context menu for the process and choose Disable process or Enable process.
Set the default process
To have an inherited process preselected for other projects you plan to create, set it as the default. This action ensures that any new projects automatically use the inherited process you choose.
To set a process as the default, open the … context menu for the inherited process and choose Set as default process. This option isn't available with any of the system processes.
Project Collection Administrators can add projects from the Projects page.