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:
- 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
Manage Workflows section.
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
Manage Workflows button, 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 Manage Workflows button,
click on the "+" icon to the left of the state, then click on the
Manage link to the right of the Transitions heading.
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>"
- 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.
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,
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.
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
or prompt the user to choose the next state or assignee.
To define Task Fields for each state transition:
Use the following questions to help you define Task Fields for each transition:
- Click on the Admin icon on the Button Bar
- Click on the Managing Workflows button
- Select the desired workflow in the Workflows pulldown at
the top. The page will be refreshed to show the properties of the selected workflow
- Click on the "+" icon to the left of Available States
to expand the list of states in the selected workflow.
- Click on the "+" icon to the left of the state that contains
the transition you wish to modify
- Click on the Manage link to the right of Transitions
- 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
- 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
- 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
- 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 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:
More information about Transitions and Task Fields can be found in the
Workflow Transitions Help section.
- 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 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:
- 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
- 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
- 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
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