ms.service | ms.author | author | ms.prod | ms.topic | ms.date |
---|---|---|---|---|---|
azure-devops-boards |
chcomley |
chcomley |
azure-devops |
include |
07/17/2020 |
You can customize the workflow of any work item type (WIT) by hiding inherited states or adding custom states. Inherited states vary based on the system process that you selected to create your custom process. The options are Agile, Basic, Scrum, or Capability Maturity Model Integration (CMMI). For more information, see Workflow states, transitions, and reasons.
Each default workflow for each WIT defines between two and four states and specifies the following workflow operations:
- Forward and backward transitions between each state. For example, the Basic process Issue WIT includes three states—To Do, Doing, and Done.
- Default reasons for each state transition
:::row::: :::column span=""::: State types :::column-end::: :::column span="2"::: Supported customizations :::column-end::: :::row-end:::
:::row:::
:::column span="":::
:::image type="icon" source="/azure/devops/organizations/settings/work/media/process/inherited-icon.png"::: Inherited states
:::column-end:::
:::column span="2":::
- Hide or unhide a state
- Add rules when changing a workflow state
:::column-end:::
:::row-end:::
:::row:::
:::column span="":::
Custom states
:::column-end:::
:::column span="2":::
- Add a workflow state
- Edit a workflow state (change color or category)
- Remove a workflow state
- Add rules when changing a workflow state
:::column-end:::
:::row-end:::
- Define at least one state for either the Proposed or In Progress State categories.
[!NOTE]
Before you add a workflow state, see About workflow states in backlogs and boards to learn how workflow states map to state categories. - Define at least two workflow States.
- Define a maximum of 32 workflow States per work item type.
::: moniker range=">= azure-devops-2020"
- Hide inherited states if you don't want them visible (you can't change their name, color, or category).
- Ensure only one state exists in the Completed state category. Adding a custom state to this category removes or hides any other state.
- Keep the name of custom states as is; you can't change them.
- Use default reasons for state transitions, such as Moved to state Triaged and Moved out of state Triaged; you can't specify custom reasons.
- Accept the default location of the State and Reason fields on the form; you can't change their placement.
- Use the default state category names; you can't customize them.
::: moniker-end
::: moniker range=" < azure-devops-2020"
- Hide inherited states if you don't want them visible (you can't change their name, color, or category).
- Ensure only one state exists in the Completed state category; the system disallows adding any custom state to this category.
- Keep the name of custom states as is; you can't change them.
- Accept the natural sequence of states in the dropdown list on the work item form; you can't change their order.
- Use default reasons for state transitions, such as Moved to state Triaged and Moved out of state Triaged; you can't specify custom reasons.
- Accept the default location of the State and Reason fields on the form; you can't change their placement.
- Allow transitions from any state to another; you can't restrict transitions.
::: moniker-end