Was this page helpful?
Your feedback about this content is important. Let us know what you think.
Additional feedback?
1500 characters remaining
Export (0) Print
Expand All
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>
NoteNote

State names and reasons are case insensitive.

See Also

Community Additions

ADD
Show:
© 2015 Microsoft