|Important||This document may not represent best practices for current development, links to downloads and other resources may no longer be valid. Current recommended version can be found here.|
States, Transitions, and Reasons
The workflow section of the work item type definition describes the valid states, valid transitions, and valid reasons for the transitions. As part of the workflow definition, you can enumerate reasons. Reasons identify why the user is changing a work item from one state to another.
The following example shows a workflow section of the work item type definition. It defines two states, two state transitions, and at least one reason for each state transition:
<WORKFLOW> <STATES> <STATE value="Active" /> <STATE value="Complete" /> </STATES> <TRANSITIONS> <TRANSITION from="" to="Active"> <REASONS> <REASON value="New"> <REASONS> </TRANSITION> <TRANSITION from="Active" to="Complete"> <REASONS> <REASON value="Deferred"/> <REASON value="No Plans to Fix"/> </REASONS> </TRANSITION> </TRANSITIONS> </WORKFLOW>
Exactly one transition must be defined to move the work item from nothing, as shown in bold text in the previous example, to a named state. This transition identifies the initial state for a new work item. Every transition must define at least one reason.
The smallest workflow for a work item must contain one state, one transition, and one default reason. The following example shows the smallest workflow you can define.
<WORKFLOW> <STATES> <STATE value=”EXISTS” /> </STATES> <TRANSITIONS> <TRANSITION from=”” to=”EXISTS” /> <REASONS> <REASON value=”New”> </REASONS> </TRANSITIONS> </WORKFLOW>
State names and reasons are case insensitive.