Central to a 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 a workflow. A workflow is associated with a Form within a Project. Multiple workflows can be created. Each form can only use one workflow within a Project, but multiple forms can use the same workflow within a Project as in the Example below:

Project 1

• Form 1 using Workflow 1
• Form 2 using Workflow 1

• Form 1 using Workflow 2
• Form 2 using Workflow 1

Workflows are created in the Workflows section.

States

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 or a group. 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 or a Support or Help Desk engineer must resolve an issue. By identifying the tasks that must be performed to process a request, you will have a good starting point for defining a 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. Transitions are paths that move records from one state to another. In the simplest case, the states are arranged in a single linear order, where at each point in the workflow, the only option (a single transition) 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 using multiple transitions. 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. Tracker allows you to define any number of states in a workflow and also optionally an unlimited number of transitions to and from each state.

To add, remove or edit a state in a workflow, click on the Admin icon in the Button Bar and then click on the Workflows link, then click on the States button. Detailed information on configuring workflow states can be found in the Workflow States Help section. To add, remove or edit transitions for a state, click on the Admin icon, click on the Workflows link, click on the "+" icon to the left of the state, then click on the Manage link to the right of the Transitions heading.

Transition State

When creating transitions, you need to decide what is the New State for the record. In other words, where does the record go when a particular transition is used to process it?

To help you develop transitions for each state, answer the following questions about each state (or step in your process):

• Does this state have a path (transition) to another state(s)?
  If there is more than one possible state, add one transition for each possible new state or you may decide to create a single transition that will allow the end user to choose the next state from a list of possible states using the "Prompt with State Group" option. If there is a need to send a record back to the last state it was in, use the "<Previous State>" option.

• Can an update transition occur for this state?
  This type of transition allows changes to be made to fields of the record without moving to another state or assigning to another user. Add a transition to be used to update a record in the state.

• Is this a terminal state?
  A terminal state denotes an end to the workflow process. For example, the Closed state is a terminal state because records that are sent to this state will not be processed any further. A terminal state can also be signified by a state which does not have any transitions to other states.

Transition Assignments

A New Assignee also needs to be defined for each transition. In some cases, it may be desirable to automatically assign the record to a particular individual or to a manager who will then assign it to a particular individual.

There are many options available to choose from when determining the New Assignee for a transition:

• Should the record be assigned to an 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) using the "Prompt with User Group" option, 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 Tracker to allow users to pick up records from the queue and assign the record to his or herself using the "<LoginUser>" option). If you are sending a record back to a state which the record passed through earlier in the workflow, you can automatically assign the record to the user who last worked on the record in that particular state using the "<Last Assignee for New State>" or "Last Assignee for <State>" options.

• Should the record be assigned to a 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 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.

• Should the record be assigned 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.

• 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 record back to the state where the fix is completed and assign the record to the original developer who completed the fix.

• Are there cases where a record does not need to be re-assigned?
  If the transition is to be used for updating a record and the assignee should not change, choose the "<Same Assignee>" option.

Transition Data

Another important issue is determining what data should be entered by a user when he/she has completed a task. This information, known as Task Fields is kept in the data form 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 form 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. Tracker allows this via the Task operation. This operation presents the user with only the fields defined for the particular state transition and can automatically change the record state and assignee or prompt the user to choose the next state or assignee.

To define Task Fields for each state transition:

1. Click on the Admin icon on the Button Bar
2. Click on the Workflows link
3. Select the desired workflow in the Workflows pulldown at the top. The page will be refreshed to show the properties of the selected workflow
4. Click on the "+" icon to the left of Available States to expand the list of states in the selected workflow.
5. Click on the "+" icon to the left of the state that contains the transition you wish to modify
6. Click on the Manage link to the right of Transitions
7. 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.

• Which fields need to be filled in or updated when the record is processed by this transition?
  For fields that need to be filled in or updated, decide whether the fields should be "Optional" for the user to fill in or "Required" using the Input Type option.

• Are there fields that should be displayed for the users reference during the Task operation?
  Task fields can be set as "Read Only" so the user can refer to the contents of the field, but cannot make changes to the field using the Input Type option.

• Are there fields that should be initialized?
  There may be cases where you wish to have fields reset to their default value during the Task operation or you may want a Date field to be initialized with the current date and time using the Initialize (Reset) option. If you wish to automatically capture a date and time in a field (e.g. a "Close Date" or "Fixed Date"), set Initialize (Reset) to "Yes" for the Date field.

• Should an Annotation to TextArea fields be set to happen automatically?
  An Annotation that includes a date and time stamp and the User ID of the user who modified the field can be set to occur automatically if desired using the Annotate option.

• Should the existing data in TextArea fields be preserved?
  The Append option allows you to define whether any data added to TextArea fields is appended to the field vs. allowing a user to modify any part of the field's contents.

Additional Options for Transitions

Additional options include choosing which transitions are visible to user groups, whether a history comment should be set, whether to allow users to add/remove attachments and source code files and whether to allow a record to be cloned during the Task operation.

To help decide which additional options are appropriate for each transition:

• Do you wish to have users explain what they are doing to the record?
  If so, you may wish to make the History Comment "Required" for a transition. Any information typed into the History Comment field will be saved in the Record History.

• Should users be allowed to add/remove Attachments or Source Code Files when using a particular transition?
  Adding attachments might be necessary in cases where the Reporter is adding more information to a record. Adding Source Code Files might be necessary in cases where a Developer is marking a record as fixed.

• Should a record be cloned at a particular step in the workflow?
  Cloning creates a duplicate of a record. This is useful in cases where you want to link records that report a similar issue or link records that report the same issue in different products or projects.

• Which users and user groups should be able to see this transition?
  The "Make Visible To Users/User Groups" option allows you to limit which users or groups can access a transition. This is useful in cases where you have multiple users that could process a record in a single state. For example, let's say you would like to allow the "Reporter" to add more detail to a record while it is assigned to a Developer in the In Development state. You could create two transitions for the In Development state:
  1. One called "Mark Fixed" that the Developer will use to reflect that he/she has completed the development for the record. This transition is only visible to the Developers group.
  2. Another called "Update" that the Reporter can use to add more information to the record while it is In Development. This transition is only visible to the "Reporter".

• For which forms should this transition be available?
  If a particular workflow is being used with multiple forms, you can choose which forms the transition will be available for. In other words, there may be some transitions that are not relevant to all forms.

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.

The next section provides information about Email Notification.