NetResults ProblemTracker
Workflow

Overview

Central to a defect tracking process are the states that define the process. Each state encompasses its own rules regarding what action must be taken, by what individual, what data is involved, and where the request should go next within the process. The states and the behavior and rules associated with them are collectively called the workflow.

States and Transitions

In general, a state in the process can be defined as one or more actions that must be performed in a serial fashion by a single individual. In most cases, it will be a single task that must be performed by team member, for example, a developer must fix a bug, or a QA engineer must test a bug fix. By identifying the tasks that must be performed to process a request, you will have a good starting point for defining your workflow.

Once the states have been identified, you must determine the order in which they occur, and whether there are points where a record could be returned to a previous state. This information defines the state transitions. In the simplest case, the states are arranged in a single linear order, where at each point in the workflow, the only option is to cause the request to move to the next defined state. However, in some cases you may wish to give an individual the choice to move the record to one of several possible states. This is called branching. Branching from one to several possible states is useful in cases where an individual is entrusted with this decision making capability.

ProblemTracker allows you to define any number of states in your workflow, and also optionally an unlimited number of transitions to and from each state.

To add, remove, or edit a state in the workflow, click on the Admin icon in the Button Bar and then click on the Define Workflow button. Detailed information on configuring your workflow can be found in the Customizing Workflow Help section.

Transition Data

Another important issue is determining what data should entered by a user when they have completed their assigned task. This information is kept in the data record, and generally is either used to process a state further down the workflow, or to log information about how the user completed the task.

Rather than just present the entire data record for editing to the user when marking the task complete, only the necessary information should be presented. This eliminates the need for each user to know what fields are important for each state transition. ProblemTracker allows this via the Task operation. This operation presents the user with only the fields defined for the particular state transition, and automatically changes the record state.

To define the set of fields to present for each state transition:

  1. Click on the Admin icon on the Button Bar
  2. Click on the Define Workflow button
  3. Click on the Transitions button to the left of the desired state on the list in the Define Workflow section
  4. Each transition listed for the state has a Task Fields button. Click on the Task Fields button to define the set of fields to present for each transition.
More information about Transitions and Task Fields can be found in the Workflow Transitions Help section.

Note that if all users are sophisticated enough to understand the entire workflow, it may be acceptable or preferable to have all users to mark a task complete by using the Edit operation instead, as this allows full access to all fields of the data record.

Transition Assignments

One final issue related to workflow is who should be assigned to each state. On a state transition it may be desirable to automatically assign the record to either a particular individual, or to a manager who will then assign it to particular individual.

There are many options available to choose from when determining your workflow. For example:

Option 1 - Assign to individual
Choosing to automatically assign a record to a particular user on a state transition has the advantage that no manager intervention is required, and the record becomes the user's responsibility as soon as possible. However, it does not allow for flexibility in scheduling resources - for example if you have several individuals who are capable of handling the task, only one of them can be assigned the job under this scheme.

In addition to choosing a specific user as the assignee, you can choose a new assignee from a list of users that are members of a particular user group (such as the "Developers" group), assign the record to the "Reporter" (the user who added the record), or allow users to assign records to themselves (e.g. you can set up a "queue" in ProblemTracker to allow users to pick up records from the queue and assign the record to his or herself).

Option 2 - Assign to manager
Assigning to the manager responsible for the state means that a manager must manually assign the record to another user for completion. This allows the manager to allocate resources more dynamically. One drawback to this scheme, is that it is difficult for someone to determine if the record is waiting to be assigned for completion, or if it has been assigned and is in the process of being handled.

Option 3 - Assign to manager using a state
Another option is to define a separate state for the task of assigning the record to an individual for processing. That is, when a task is marked complete, it is assigned to a new state with a particular manager. The only task associated with the state is for the manager to assign it to somebody, at which point it moves to the state associated with actually handling the work. For example, rather than a single state called "Scheduled" which covers both assignment and completion of the task, you might define two states called "Scheduled" and "In Development". In this case the "Scheduled" state only covers the assignment, while the "In Development" state covers the actual work.

Option 4 - Assign to last assignee for new state
In some cases, you may want to assign a record to a user who was previously assigned to it in a state earlier in the workflow process. This option is useful in situations where an approval decision is made. For example, when a QA engineer has to verify a fix. If the fix cannot be verified, the QA engineer may need to move the problem record back to the state where the fix is completed and assign to problem record to the original developer who completed the fix.

ProblemTracker is flexible enough to support any of these options, as well as others not listed. A complete list of options can be found in the Workflow Transitions Help section.