Defining Workflow Rules

Workflow rules allow you to define and enforce an issue handling process. Together with e-mail notifications, workflow rules help you automate the tracking and management of issues.

What Can You Do with Workflow Rules?

Overview

Select choices in other choice lists.

Change the possible choices in other choice lists.

These are the basics of workflow rules. However, this explanation leaves out some important details.

By default, rules are applied when a user creates, saves, or loads an issue. If necessary, you can force rules to be evaluated when a user selects a choice.

Workflow rules can also be based on more complicated conditions. For example, a rule may require that certain choices are selected from a number of different choice lists, or that the user is a member of a specific group, or both.

Automate Workflow

By controlling the possible values of the Progress field, you can define and enforce a process.

Simple workflow controlled by Progress values

Example 1:

After an analyst starts work on an issue and marks it In Progress, you can enforce a process where only the analyst can mark the issue as Dropped, Resolved, or To be Verified.

When:
	<User in Group> = Help Desk Analyst AND
	Progress = In Progress 
The possible values are: 
	Progress = Dropped
	Progress = Resolved
	Progress = To be Verified

Note that Progress = In Progress is an implied possible value. A choice list can always be set back to its current value. For example, if a user is not a help desk analyst and an issue is marked In Progress, the Progress list contains only one choice: In Progress.

Example 2:

When:
	<User in Group> = Help Desk Group Leader AND
	Progress = New 
The possible values are: 
	Progress = Assigned

This prevents new issues from being resolved or dropped without first being assigned to an analyst by the group leader. If a user is not a group leader, the only possible choice will be New.

Create Related Choice Lists

Example:

Suppose that Problem Type can be either Hardware, Software, or System. Problem Area can then be a type-specific list that displays either a list of hardware components, software applications, or system components.

When:
	Problem Type = Hardware 
The possible values are: 
	Problem Area = Disk
	Problem Area = Monitor
	Problem Area = Keyboard
	Problem Area = Memory

By default, workflow rules are evaluated when an issue is saved. For related choice lists like the ones in this example, you probably want to evaluate the rule whenever the Problem Type changes. Otherwise, users would have to select a Problem Type, save the issue, and then select the Problem Area.

Set Field Values

Instead of setting the possible values of a choice list, you can define rules that select choices from other lists. These type of rules are called a dependent values rules, because they make the value of one field depend on the value of another field.

Example:

When:
	Owner = <None> AND
	Problem Area = SW - Outlook 
The values to set are: 
	Owner = Erick Yanez

The default owner for new issues in <None>. So this rule assigns a default owner for new issues, but allows the issue to be reassigned later. Without the Owner = <None> part, you could never change the owner of the issue.

Set Default Values

You can set the default value of a choice list with either a dependent values rule or a possible values rule.

Example 1: Dependent values rule

When a user creates a new issue, the Priority field is empty. If you want, you can make Today the default priority for new issues.

When:
	Priority = <Empty> 
The values to set are: 
	Priority = Today

Example 2: Possible values rule

You probably want new issues marked as New in the Progress field. You can do this by specifying the possible values when Progress is empty.

When:
	<User in Group> = Users AND
	Progress = <Empty> 
The possible values are: 
	Progress = New

The <User in Group> = Users test defines a default behavior. You can override this behavior by creating rules for specific groups (for example, a rule that includes a <User in Group> = Admins test).

What You Should Know about Workflow Rules

Rules are defined per project

All Web views of a project share the same workflow rules. You cannot disable the workflow rules for specific Web views. The rules are either enabled for all views or disabled for all views.

Rules can impact performance

Using workflow rules to set default values is a good choice if you have a small number of rules and are not limited by resources (server, network, end-user computers).

Rules are evaluated when issues are saved, loaded, and created

By default, workflow rules are evaluated when an issue is saved, loaded, or created. You can force rules to be evaluated when a user changes the value of one of the fields specified in the condition. Evaluating rules on field changes has a potentially higher performance cost.

Rules work with single-choice list fields

You cannot define rules that apply to any other type of field, including multiple-choice list fields.

Changes to choice lists can break workflow rules

If you remove choices from a choice list, or change the meaning of a choice, rules that use the choice list may stop working or result in unexpected behavior.

By default, rules apply to all users

To build group-specific rules, use the macro <User in Group> in your conditions.

The order of rules is important

Rules are evaluated in the order they are listed in the Workflow Editor. For example, in the default workflow, the rule Admins-<Any> is the first rule in the list. This ensures that any member of the Admin group can make any change to the Progress field.

If the Admins-<Any> rule was last, then a help desk analyst who is also a member of Admins does not have full administrator permissions for changing the Progress field. The stricter HelpDesk Analyst rules would be evaluated first, limiting the changes the analyst can make.

What is a Workflow Rule?

if ( condition ) then 
	action

If a user belongs to a specific group

If a specific choice was selected from a choice list.

Multiple conditions can be joined with a logical AND. The only test operator available is the equal to operator (=).

If the rule is a possible values rule, the action can specify the possible values for one or more choice lists. If the rule is a dependent values rule, the action can select choices from one or more choice lists.

Understanding Templates and Rules

Templates define the fields used in rules, and rules provide the values. For example, a template might look like this:

When:
	<User in Group> = _ _ _ _ AND
	Progress = _ _ _ _  
The possible values are: 
	Progress = _ _ _ _

Each rule fills in the _ _ _ _ parts with specific values. A template defines what the rules look like, while a rule actually fills in the blanks.

Creating Rule Templates

To create a rule template:

In the Project list, click a project.

Click Template, click Add, and then type a descriptive name in the Template Name box.

If you want to add some comments or a brief description of the template, type them in the Template Description box.

Click the type of rules the template defines.

A possible values rule specifies the available choices in one or more choice lists. A dependent values rule selects choices from one or more choice lists.

Defining Conditions for User Groups

By default, a rule applies to all users. To build group-specific rules, use the macro <User in Group> in your conditions.

If a user belongs to a group for which there is no rule, then for possible values, the fields displays all possible values.

Rules that apply to the Users group apply to all users, because all users are members of the Users group. Rules for specific groups can override the base rule defined for the Users group.

Defining Rules

To define a rule:

In the Project list, click a project. Then click a rule template.

Click Rule and then click Add.

On the Conditions and Possible Values (or Dependent Values) tabs, fill in the values for each row.

Click Apply to apply the rule to the Web views of the project.

You can also copy a rule and edit it. To copy a rule, click the rule. Then click Rule, click Copy, and type a name for the new rule.

Deleting Rules

To delete a rule:

In the list, click a rule.

Click Rule and then click Remove.

Click Apply to apply the changes to the Web views of the project.

Renaming Rules

To rename a rule:

In the list, click a rule.

Click Rule and then click Rename.

Type the new name for the rule.

To change the default names for new rules:

In the list, click a rule template. Click Template and then click Properties.

In the Name rules according to box, type the new default name for rules.

By default, rule names are based on the condition values (the values entered in the Value column). The string %Value0% represents the value in the first row of the condition, %Value1% represents the value in the second row, and so on.

If you use a text string (such as "WorkflowRule") as the default rule name, rule names are formed by appending a number to the string.

Using Macros in Rules

<Any>

Use the <Any> macro in conditions to define a rule that applies to any value of a field, including <Empty>. For example, in the default workflow, the Admins-<Any> rule allows members of the Admins group to set any value in the Progress field.

<Empty>

Use the <Empty> macro in conditions to define a rule that applies when a field is empty.

<User>

<User> represents the current user (the user currently logged on to the Web view). You can use <User> in conditions, as a possible value, and as a dependent value.

Setting Possible Values

When you set the possible values of a field, you don't have to include the current value of the field in the list of possible values. For example, given this rule:

When:
	<User in Group> = Employees AND
	Progress = Waiting 
The possible values are: 
	Progress = Dropped
	Progress = In Progress
	Progress = Resolved

then when Progress is set to Waiting, the Progress list will contain Dropped, In Progress, Resolved, and Waiting.

Changing When Rules Are Evaluated

By default, workflow rules are evaluated when an issue is saved. The rules are also evaluated when issues are loaded (so workflow rules apply to existing issues too) and when issues are created.

However, you can force rules to be evaluated when a user changes the value of one of the fields specified in the condition. Keep in mind that evaluating rules on field changes can have a potentially higher performance cost.

To evaluate rules on field changes:

In the list, click a template.

Click Template and then click Properties.

Select the Evaluate rules when users change field values check box.

In the Template Properties dialog box, click Ok.

Click Apply to apply the change to the Web views of the project.

Applying Workflow Rules

When you edit a rule, define a new rule, define a new group of rules, or change the group options, you must apply these changes.

To apply workflow rules:

In the list, click a template.

Click Apply.

Apply automatically enables the group of rules. If you just enable the rules, but don’t apply them, nothing happens.

Web view users must log out and then log back on before the changes take effect.

Disabling Workflow Rules

To disable workflow rules:

In the list, click a template.

Click Template and then click Properties.

Clear the Enable in all Web views of the project check box, and click OK in the message box that appears.

In the Template Properties dialog box, click OK.

Click Apply to apply the change to the Web views of the project.