This documentation is archived and is not being maintained.

When and Where to Apply a Field Rule

You can use field rules to determine work item type behavior regardless of the state of the work item. For example, a field that is required for a bug that is new and active remains required until the bug is closed.

Field rules can also be scoped to certain states, transitions, and even reasons. The complete set of rules that apply to any particular field is additive from the following four subsets:

  • Work item type-specific

  • State-specific

  • Transition-specific

  • Reason-specific

Work item type-specific rules apply regardless of the location of a work item in its state model. For example, a <REQUIRED /> rule performs the following check:

"MyField Value" != NULL

State-specific rules are scoped to a work item instance when it is in a certain state. A state-specific rule is enforced when the following condition is true:

State field value == "MyState" && "MyField Value" != NULL

Transition-specific rules are scoped to a work item that is undergoing a certain transition. Transition-specific rules are enforced when the following conditions are true:

State field value == "ToState"  &&

"Previous State Before Edit/New" == "FromState"

&& "MyField Value" != NULL

Reason-specific rules are scoped to a particular reason for a particular transition. Reason-specific rules are processed when the following conditions are true:

Reason field == "MyReason" &&

State field value == "ToState"  &&

"Previous State Before Edit/New" == "FromState" && "MyField Value" != NULL

You can apply scope to field rules by using the FIELDS and FIELD (Workflow) elements within the STATE, TRANSITION, and REASON elements.


When you list fields in the workflow, specify only the field reference name.


The following example defines the following rule: When a bug is in the Active state, do not allow the customer severity field to be modified.

<STATE name="Active">
<FIELD refname="MyCorp.Severity" >