Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Azure DevOps Services | Azure DevOps Server | Azure DevOps Server 2022
Each project is based on a process that defines the building blocks for tracking work. The first project you create uses one of the default processes—Agile, Basic, Scrum, or CMMI.
You can only customize inherited processes. Any changes you make to the inherited process automatically appear in the projects that use that process. To customize a project, follow this sequence:
- Customize an inherited process: Modify fields, work item types, workflows, forms, and backlogs to align with your requirements.
- Verify your customizations: Create a test project and validate your changes.
- Apply the inherited process to a project: Create a new project based on the inherited process, or change the process used by an existing project.
- Refresh and verify: Refresh the web portal and open a work item of the type you modified.
Important
The Inheritance process model is available for projects that are configured to support the model type. If you use 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 Organization-level process customization.
Note
You can review changes made to an inherited process by using the audit log and auditing features. For more information, see Access, export, and filter audit logs.
Tip
You can use AI to help with this task later in this article, or see Enable AI assistance with Azure DevOps MCP Server to get started.
Prerequisites
For guidance on tailoring Azure Boards to align with your specific business requirements, see Configure and customize Azure Boards.
| Category | Requirements |
|---|---|
| Permissions | - To create, delete, or edit a process: Member of the Project Collection Administrators group or specific collection-level permissions Create process, Delete process, Edit process, or Delete a field from organization set to Allow. For more information, see Customize an inherited process. - To update boards: Team Administrator or a member of the Project Administrators group. |
| Access | - Even if you have Basic or lower access, you can still change a process if someone gives you permission. - To update and change the type of your existing work items: Member of the project. |
| Project process model | - Have the Inheritance process model for the project collection containing the project. - To migrate data to Azure DevOps Services, use the Team Foundation Server Database Import Service. |
| Knowledge | - Familiarity with the customization and process models. |
Note
When you customize an inherited process, any projects that use the process automatically reflect the customizations. To ensure a smooth transition, we recommend that you create a test process and project to test your customizations before you implement them organization-wide. For more information, see Create and manage inherited processes.
Add or modify a field
Locked 
fields and inherited 
fields correspond to fields from a system process.
You can't customize locked fields, but you can customize some options for inherited fields.
You can fully customize fields that you add to a process.
Sign in to your organization (
https://dev.azure.com/{yourorganization}).Select
Organization settings.
Select Process > your inherited process > the WIT you want to customize.
To add a field, select the
(New Field icon).
In the dialog, select the type of field that you want to add. For example: integer, picklist (dropdown menu), person-name/Identity, rich-text or HTML, or checkbox (boolean).
Modify an existing field in the following ways:
Add or modify a rule for a work item type
Add rules to support specific workflow and business use cases. Rules let you clear the value of a field, copy a value into a field, and apply values based on dependencies between different fields' values.
- Select your inherited process and the work item type.
- Select Rules > New rule.
For more information, see Rules and rule evaluation.
Add or modify work item types
Use different work item types (WITs) to plan and track different types of work. Add a custom WIT to customize the web form and workflow states for specific business use cases.
Select your inherited process and the WIT you want to customize.
From the Work Item Types page, select the
New work item type.
Name the WIT and optionally specify a description, icon, and color. The icon and color appear throughout the web portal, including on the work item form, backlogs, boards, and query results.
Select Create to save.
You can now add fields to the WIT or customize it in the following ways:
Modify the workflow of a work item type
Workflow states help you track the status of a work item as it moves from new to completed.
To modify a workflow, select your inherited process, the work item type, and then the States page.
Modify the workflow by using the following options:
Add a custom control
Custom controls add more functionality to a work item form.
From the Process page, select your inherited process, select the work item type, and then select Add custom control.
Add an extension to a work item type
An extension is an installable unit that adds new capabilities to your project.
Note
Group and page extensions automatically add to all work item types (WITs) for all processes, both system and inherited. You can hide an extension for selected WITs within an inherited process.
Go to the Visual Studio Marketplace, find an extension, and select Get it free.
Select the organization you want to add it to from the dropdown menu, and then select Install.
Return to the process and WIT and verify the extension is where you want it. You can drag it to where you want it on the form.
Modify the backlog and boards
You can add more work item types (WITs) to a backlog level or create another portfolio backlog. For example:
- You introduce a third-level portfolio backlog called Initiatives to track the custom Initiative WIT.
- You rename the product backlog to Stories and Tickets to encompass both User stories and Customer tickets.
From the Process page, select your inherited process and then select Backlog levels.
Modify the backlog and board configuration in the following ways:
Verify your customization
Create a test project and apply your customized inherited process to verify your changes. All customizations to a process take effect immediately on all projects. To stage your changes, use one of the following methods:
- Create a test project and copy of your customized process
- Create a test organization and import/export your process
Create a test project and copy your customized process
From the Process page, select the … context menu for the process you want to use, and then select New team project.
Enter information into the form, and then select Create. For more information, see Create a project.
From your project, select Boards > Work Items, and then select the customized WIT from the New Work Item dropdown menu. In the following example, select Bug.
Verify that the fields you added appear on the form. The
(exclamation mark) icon indicates the field is required.
Create a test organization and import or export your process
Use the following steps to verify the customizations you made to an inherited process.
- Create a test organization.
- Use the import/export process tool to copy the process to the test organization.
- Verify the process customizations in the test organization.
- Use the import/export process tool again to import the modified process to the production organization.
Change your project's process
For more information, see Change a project's process.
Use AI to customize your project process
Tip
You can use AI to help with this task later in this article, or see Enable AI assistance with Azure DevOps MCP Server to get started.
If you use GitHub Copilot, the Azure DevOps MCP Server can help you customize inherited processes for your projects through natural language prompts.
Example prompts for process customization
| Task | Example prompt |
|---|---|
| Plan a full process customization | I'm adopting an inherited Agile process for a regulated healthcare project. Walk me through adding custom fields for Compliance Status and Regulatory Reference, a new 'Compliance Review' state, and rules that enforce sign-off before items can move to Done |
| Add a custom work item type | Create a 'Risk' work item type in my inherited process with fields for Likelihood, Impact, Mitigation Plan, and Risk Owner. Add it to the Requirements backlog level so it shows on our board |
| Verify customizations in a test project | I made several customizations to my inherited process — new fields, a custom WIT, and modified workflow states. Help me create a test project to validate everything works correctly before applying the process to our production project |
| Compare two inherited processes | I have two inherited processes, TeamAlpha-Agile and TeamBeta-Agile. List the differences between them in fields, work item types, states, and rules so I can decide whether to consolidate into one process |
| Troubleshoot customization problems | After customizing my inherited process, some fields aren't appearing on the work item form and a custom state is missing from the board. Help me diagnose what went wrong and how to fix it |
| Revert unwanted customizations | I made changes to the Bug work item type in my inherited process that are causing problems. Show me how to revert specific field and layout changes back to the default inherited behavior without losing other customizations |
Tip
For the best results, use these prompts in agent mode with the Azure DevOps MCP Server connected. Customize the prompts with your specific process name, work item types, or business requirements.