Use workflow rules to create field relationships

Additional Notes and Considerations

• In a real implementation, you would expand the list of functional areas to cover the other issue types (such as software enhancements and online help defects) and define workflow rules for those other issue types.

• When you use workflow rules to set the possible values of a choice list field, the field won't be empty when a user creates a new issue. The field will display the first choice in the list.

  If, like Functional Area, the field is not a required field, this may become a problem. Over time, as users submit issues, you may end up with a large number of issues with the wrong functional area. For example, you might end up with a lot of documentation defects logged against the Admin Guide, just because it is the first choice in the list.

  To avoid this problem, you can add an < Unspecified > choice to the Functional Area list, and then update the workflow rules to include < Unspecified > as a possible value. When a user creates a new issue, Functional Area will be set to < Unspecified >.

• You can use a rule with a Type = <Any> condition to handle all issue types that are not handled by specific rules. Just make sure it is the last rule. For example, in the following, the <Any> rule sets the possible functional areas for any issue that is not a documentation or software defect:

  

  Census stops evaluating rules as soon as it finds a rule that applies, so if the <Any> rule was first, the other rules would never be evaluated.