TRANSITION XML element
VSTS (Hosted XML) | TFS 2018 | TFS 2017 | TFS 2015 | TFS 2013
This topic applies to team project customization for Hosted XML and On-premises XML process models. For the Inheritance process model, see Customize a process. For an overview of process models, see Customize your work tracking experience.
You use the TRANSITION element to specify a valid progression or regression from one state to another for a type of work item. The TRANSITION element is a required child element of the TRANSITIONS element.
To modify the workflow, you modify the definition for a work item type. See Modify or add a custom work item type.
<TRANSITION from="NameOfStartingState" to="NameOfEndingState" for="UserGroupName" not="UserGroupName"> <ACTIONS> . . . </ACTIONS> <REASONS> . . . </REASONS> <FIELDS> . . . </FIELDS> </TRANSITION>
Attributes and elements
The following sections describe attributes, child elements, and parent elements.
||Required. The name of the state from which the work item is transitioning.|
||Required. The name of the state to which the work item is transitioning.|
Optional. The name of a user or group who is allowed to perform the transition.
Optional. The name of a user or group who is restricted from performing the transition.
|ACTIONS||Optional. Defines a collection of
|REASONS||Required. A collection of
|FIELDS (Workflow)||Optional. A collection of
|TRANSITIONS||Required. A collection of
TRANSITION is a required child element of
You must define exactly one transition to move the work item from nothing (
from="") to a named state such as Active. This transition identifies the default state for a new work item.
All valid transitions between two states must be specified. If no transition is specified, then by default no transition is allowed.
Additionally, you can optionally use the attributes
not in the transition element of workflow to refine who is and who is not able to perform a transition. When you do this,
denies takes precedence over
allows. If neither of these attributes is specified, anyone can modify the work item.
Multiple groups are supported only by creating a parent group and specifying that parent group in the
TRANSITION element. To learn more about the for and not attributes, see Apply a field rule.
In the following example, the reasons are defined for the transition from the Active to the Resolved workflow state.
<TRANSITION from="Active" to="Resolved"> . . . <REASONS> <DEFAULTREASON value="Fixed"/> <REASON value="Deferred"/> <REASON value="Duplicate"/> <REASON value="As Designed"/> <REASON value="Unable to Reproduce"/> <REASON value="Obsolete"/> </REASONS> . . . </TRANSITION>
In the following rule, the ability to transition a work item from the Resolved to the Completed state is restricted to all project testers, except for new testers who have just joined the team.
<TRANSITION from="Resolved" to="Complete" for="[project]\AllTesters" not="[project]\NewTesters"> </TRANSITION>
Auto completion of work items with pull requests
When you link a work item to a pull request (PR), you have the option to automatically complete those work items when you successfully complete the PR.
Feature availability: The Complete linked work items after merging option is available from VSTS only at this time. It will become available with the release of TFS 2018 RTW.
To learn more, see Workflow states & state categories.