Prepare for the installation
Install Tracker on your server
Add a Workgroup
Define your process
Set up the projects
Create forms
Set up the users and user groups
Customize the fields
Configure the workflow
Customize the Email Notifications
Create Reports and Configure Preferences
Configure Add-On Features
Test and Rollout

Prepare for the Installation

Ensure that your server fulfills the System Requirements (option #1 on this page). There is a section on that page that helps you prepare the server for the installation.

Install Tracker on Your Server

Install Tracker using the Installation Instructions (option #3 on this page).

Add a Workgroup

Add a workgroup using the Workgroup Management System.

Define your process

The first step is to determine what you will be tracking. The following questions can guide you in this step:

• What projects will be managed?
• What are the processes or forms associated with managing these projects?
• What data needs to be collected during those processes and on those forms?
• What steps are needed to complete the processes?
• Who completes the steps at each point in the processes?

You can document your process as a written specification or a graphical flow chart. Here's an example of a very simple process as a list of sequential steps:

1. A customer reports an issue which includes a summary of the problem, the product and version they are using, a detailed description of the problem and can attach any files that help describe the issue in more detail (e.g. a screen shot of the error).

2. The Process Manager reviews the issue and decides what to do with it. If it is something that needs to be fixed by a developer, the issue is assigned to a version and given a priority.

3. The Development Manager assigns the issue to a Developer.

4. The Developer fixes the issue and explains what was done to fix it.

5. The QA Manager assigns the issue to a QA Engineer for testing.

6. The QA Engineer tests the fix for the issue.

7. The Build Manager bundles the fix into a released version of the product.

Once you've documented your process and indentified who is performing the work at each step and what data is to be collected, you can configure the process in Tracker using the information in the rest of the sections.

For example, using the sample above, we can translate pieces of this written process into areas to be configured in Tracker:

1. A customer reports an issue which includes a summary of the problem, the product and version they are using, a detailed description of the problem and can attach any files that help describe the issue in more detail (e.g. a screen shot of the error).

   The first step is adding an issue. All of the data collected when an issue is reported become fields on the Add Page.

2. The Process Manager reviews the issue and decides what to do with it. If it is something that needs to be fixed by a developer, the issue is assigned to a version and given a priority.

   This step and each one after it becomes a state with at least one transition in the Workflow. The fields filled out at each step become task fields (fields that are displayed as part of a particular transition).

3. The Development Manager assigns the issue to a Developer.

4. The Developer fixes the issue and explains what was done to fix it.

   You may want to be able to report on some critical actions in your process. For example, you want a report of the number of issues fixed by each developer or the number of issues that were fixed last month. Generating these types of reports require that you configure fields to capture the appropriate data as records are being processed. You'll need to create a "Fixed By" field to capture the developer who fixed an issue and a "Fix Date" field to save the date when an issue was fixed.

5. The QA Manager assigns the issue to a QA Engineer for testing.

6. The QA Engineer tests the fix for the issue.

7. The Build Manager bundles the fix into a released version of the product.

Set up the projects

The Tracker structure is made up of:

• Project(s) – A project is a plan or design. It can be a collection of records or tasks that are completed by a particular set of users or groups.
• Form(s) – A form is a set of fields that combined make up a particular "record".
• Workflow(s) – A workflow is a set of steps that represents a process.

The relationship between Project, Form and Workflow isn’t strictly hierarchical. A Project has one or more Forms available for use in the Project. Each Form within a Project has one (and only one) Workflow associated with it for that Project (for use when an instance of that Form is created via the Add operation in that Project). The same Form may be used in other Projects with other Workflows. The same Workflow may be shared by multiple Forms (in the same Project or in different Projects). Workflow and Form are always related. Every Workflow is associated with (available for) at least one Form. Here are some examples of multiple Projects, Forms and Workflows handled in a single workgroup:

Example 1: Product Development and Customer Support

One project for each "area", each project has its own form(s) and workflow.

Project 1: Product Development
Form: Issue using a "Product Issue Process" workflow

Project 2: Customer Support
Form 1: Ticket using a "Support Ticket Process" workflow
Form 2: Customer Contact Information (no workflow)

Project 3: Knowledge Base
Form: Article using a "Knowledge Base Article Process" workflow

Example 2: Product Development

One project for each product so that users only see the projects related to the products in which they are involved.

Project 1: Our Browser Product
Form: Issue using a "Product Issue Process" workflow

Project 2: Our Database Product
Form: Issue using a "Product Issue Process" workflow

Project 3: Our Spreadsheet Product
Form: Issue using a "Product Issue Process" workflow

The best order to set up Tracker is:

• Create Project(s)
• Create Form(s) and Fields
• Create Workflow(s)

Projects

One example of a project might be a line of products that are grouped together in some fashion (e.g. Project A, which includes Products 1A and 2A).

Each project that is managed in Tracker will have one or more forms available for collecting the information needed to complete the project tasks or track issues associated with the project. If you are planning to only use one project, a default project is already configured for you to use so you can skip this section and move on to the Forms section.

You may decide to use multiple projects. Each project is intended to be a very independent thing. In many ways they have been designed to be analogous to workgroups or databases (the projects happen to be in a single workgroup/database). One factor that can be important is visibility of records. If you need sets of records to only be visible to certain groups of users, then this can be done by creating multiple projects. For example, you only want user group A to access Project A records and not Project B records. View a Flash demo that discusses examples and advantages of multiple projects.

Steps for adding a project can be found in the Projects section. Or, View a Flash demo that shows how to add a project.

Create forms

A form is a set of fields that grouped together make up a record. Examples of forms are a bug report, enhancement request, change request, support or help desk issue or Knowledge Base article.

If you are planning to only use a single form, a default form called "Record Form" is already configured for you to use so you can skip this section and move on to the Users section.

You may decide to use multiple forms. In most cases, it's more advantageous to use multiple projects rather than multiple forms. The reason is that there are a limited number of forms that can be created and there is a performance impact when performing cross-form reporting. For example, if the forms you wish to create differ only in name (they share all or most of the same fields), that is a sign that you should not use multiple forms. You can instead use multiple projects (same form in each project, but perhaps use a different workflow in each to change how the fields are set).

If the workgroup is created using a SQL Server or Oracle database and you are using multiple forms, cross-form metrics (charts & graphs) are allowed. This is only available in SQL Server or Oracle databases because they are more robust at handling the performance impact of cross-form computations.

When creating a form, you will have the option to select whether the form will be used with a workflow. In some cases, you may not intend to use a workflow with a form. For example, a form that is only used to collect contact information probably does not need a workflow. It can still be updated with the most current information without having a workflow.

Steps for adding a form can be found in the Forms. Or you can view a Flash demo that explains how to add a form.

Set up the users and user groups

Set up the necessary user accounts. This can be done in the User Management System (UMS). Or, depending on how UMS is configured, it can also be done in the User Accounts section.

Create the user groups you think you will need using the steps in the User Groups section. When creating the user groups, you may want to just accept the defaults for the user group privileges and fine tune them after you've configured the workflow and have a better idea of what actions each group will be doing in the process.

Customize the fields

Your workgroup is configured with a default set of fields. Take a look at the existing fields so you know what is already available. To do this, login as Admin, click on the Admin icon and click on the Fields link. You can click on the Edit button to the left of a field to see its properties and make changes.

When deciding which fields you need to add to the system, keep in mind what kind of information you and other users and groups involved in the projects will want to track within a single record and in reports.

Here are some examples that can help you identify the fields that you need:

Classifications & Categories
Pulldown fields allow a pre-determined list of items to be configured, making it easy to run reports that break down different aspects of your data (e.g. the type of issue being reported, severity, priority, collecting different options or components of a product or installation).

Descriptions, Explanations, Comments
A TextArea type field is designed to handle lengthy text information.

Capturing what user performed a specific action
You may want to be able to run reports that show how many issues were fixed by each developer or how many tickets were resolved by each Support or Help Desk Engineer. In order to do this, you need to create a field called "Fixed By" or "Resolved By" that will note who fixed or resolved an issue. This can be done by creating a pulldown field with the "User Pulldown" property set to "Yes".

Capturing when a specific action was performed
You may want to be able to track when a record was fixed, tested or closed. To do this, you will need to create Date fields called "Fix Date", "Date Tested", "Date Closed" to capture this data.

Linking to a related record
Records can be linked using the Link field type. Let's say there are 2 forms, a form for Support Tickets and another for Knowledge Base Articles. If you want a Support ticket to have a link to a related KB article (perhaps to reflect articles that were inspired by the content of the ticket), create a Link field called "Related KB Articles".

And, here are some questions to help you configure the properties of the fields:

• What data type should be used for the field? For example, you create a field called "Customer" in order to collect the name of the customer related to the record being reported. You could make this field a Text type field so that a name can be typed into the field. Alternatively, you could make this field a Pulldown menu where the menu options are pre-configured. Making this field a Pulldown field prevents users from typing in different versions of the same choice and makes running reports simpler.
• Where should this field be available? For example, does it need to be filled out as part of the process of adding the record via the Add or Submit pages? Or, is it something that is entered later in the process via the Task or Edit operations? You can choose whether each field is displayed on the Add, Submit, Edit and View Pages, Query and Home Page reports and email notifications. You can also choose which user groups are allowed to see the field in those areas.
• If this field is included on the Add or Submit Pages, should it be required? Making a field required ensures that a user adding a new record must enter information into the field before the new record can be submitted.

Create any other fields that will be needed for each form. The steps for adding a field are available in the Fields section. Or, view a Flash demo that provides the steps for adding a field.

Configure the Workflow

The states that define it are critical to a tracking process. Each state encompasses its own rules regarding what action must be taken, by what individual, what data is involved, and where the record 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

Your Tracker workgroup has a workflow defined. How the workflow is configured depends on the template that was selected. Review the workflow configured in your workgroup by clicking on the link below that corresponds to the template you selected. You can then decide whether to use the default workflow as is or make some adjustments.

Product Development
Web Site Development
Knowledge Base
Help Desk
Support
Base
Change Management

As you review this rest of this section, add more information to the process document you created earlier. For example, you can create an outline like the sample below and just note areas where you need to make adjustments to the existing workflow:

State 1 - Reported

Transitions:

• Schedule the issue to be fixed
  Goes to Scheduled state, assigned to Development Manager
  Task Fields:
  Priority (required), Planned for Version

• Close the issue
  Goes to Closed state, assigned to no one
  Task Fields:
  Close Detail (required), Close Date (time stamped with the current date and time)

State 2 - Scheduled

Transitions:

• Assign to Developer
  Goes to In Development state, manager picks developer from a list
  No Task Fields

State 3 - In Development

Transitions:

• Update the issue
  Does not move to another state or get re-assigned
  Task Fields:
  Fix Detail (required)
• Mark Fixed
  Goes to Fixed state, assigned to QA Manager
  Task Fields: Fix Detail (required), Fix Date (time stamped with the current date and time)

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.

In order to make use of transitions configured in the workflow, end users will need to use the Task operation to process records. However, if all users are sophisticated enough to understand the entire workflow, it may be acceptable or preferable to have all (or some) users mark a task complete by using the Edit operation instead, as this allows full access to all fields of the data record. This Knowledge Base article provides more information about deciding whether to use Edit or Task to process records.

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. In some cases, it may be necessary to send a record back to a previous state (e.g. when the fix for an issue fails testing, when a ticket gets de-escalated).

• Can an update occur on the record in this state?
  An Update 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 does not have any transitions to other states.

A New Assignee 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 (e.g. Development Manager chooses the assignee from a list of "Developers"), assign the record to the Reporter (the user who created the record), or allow users to assign records to themselves from a queue. You can also automatically assign the record to a user who previously worked on the record in a particular state (step) in the process.

• 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 scheme is that it adds a step before the record is assigned to someone and they begin working on it.

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.

Use the following questions to help you define Task Fields 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 or required.

• Are there fields that should be displayed for the user's 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.

• Are there fields that should be initialized?
  There may be cases where you wish to have fields reset to a particular value (e.g. clear out existing text or reset a pulldown field to its default value). Or, you may want a Date field to be initialized to a certain value (e.g. "time stamped" with current date and time or set to a relative date "1 week from now", "1 day before deadline").

• Are there fields that should be set without being displayed to the user?
  Fields can be configured as "invisible" so that they are set with a particular value during the Task operation, but are not shown to the user.

• Does the user need to document detailed information, explanations or comments?
  TextArea fields can be presented as optional or required and can be configured to protect the existing information in the field from being updated (append only).

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:

• 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. For example, you may want to make the History Comment required on an "Update" transition to explain what was changed. Any information typed into the History Comment field will be saved in the Record History.

• Should users be allowed to add Attachments and 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 is useful in cases where a Developer is explaining what files were affected when fixing an issue.

• 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.

• Do you need to show/hide transitions depending on user role or groups?
  You can configure transitions so that they are only available to specific user roles or groups. 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 customer who reported the issue to add more detail to a ticket before it's assigned to a Support Engineer. You could create two transitions for the Reported state:
  1. One called "Update" that the Reporter can use to add more information to the ticket. This transition is only visible to the user who created the issue.
  2. Another called "Start Processing Request" that the Support Engineer will use to assign the ticket to his/herself. This transition is only visible to the Support group.

You can also review the following KB articles that explain techniques for configuring workflow to address different situations:

How to restrict a user from processing a record that does not pertain to them
How to route records to a different starting point in the workflow based on a pulldown (e.g. Product, Priority, etc.)
How to set up an "Update" or "loop" transition
Ways to assign records in Tracker

Workflows can be added or changed in the Workflows section. Detailed information on configuring workflow states can be found in the Workflow States Help section. Information about creating transitions and task fields can be found in the Workflow Transitions section.

State Managers

While setting up the workflow to reflect your process(es), you may have decided to use the State Managers feature (for example, to assign newly added records to particular users based on product, request type, etc.). If you haven't already done so, configure the State Managers in the Projects section.

User Group Privileges

Now that you have a workflow configured, review the privileges configured for each user group to see if you need to enable any additional privileges based on what actions each user group will be performing in the process(es). For example, if you've set up a state such that the Reporter can update a record at the same time it is assigned to a Developer or Support Engineer, you'll need to ensure that the group of users who report records have the privilege "Task if Reporter in State(s)" enabled. Edit a user group to configure the privileges.

Customize the Email Notifications

An important aid to timely and smooth processing of the tracking process is automatic notification of events. Standard Internet email is the most widely accepted form of notification.

Determining which users and under what events notification should occur is really a trial-and-error process determined by the personal working habits and preferences of users of the system. This topic should be discussed and tested with the users in your organization until consensus is reached on the desired behavior.

There are several events that could trigger notification:

• Adding a record
• Editing a record
• Deleting a record
• Performing the Task operation on a record
• Change of record state
• Change of assignment

• The user who is currently assigned to the record
• The user who reported the record
• The manager assigned to the state of the record when it is added
• User Groups within your database

When an edit or task operation is performed on a record, the following users may need to be notified:

• The user who is currently assigned to the record
• The individual assigned to the record if the Assigned To field is changed during the Edit / Task operation.
• The individual who was the previous assignee if the Assigned To field is changed during the Edit / Task operation.
• The individual who reported the record.
• The manager assigned to the process state of the record when the Edit / Task operation is performed.
• The manager assigned to the new process state of the record if the State field is changed during the Edit / Task operation.
• The manager assigned to the previous process state of the record if the State field is changed during the Edit / Task operation.
• User Groups within your database

When a record is deleted, the following users may need to be notified:

• The individual who is currently assigned to the record
• The individual who reported the record
• The manager assigned to the process state of the record when it is deleted
• User Groups within your database

On a change of record state, the following users may need to be notified:

• The individual who is currently assigned to the record
• The individual who reported the record
• The manager assigned to the new process state
• The manager assigned to the original process state
• User Groups within your database

On a change of record assignment, the following users may need to be notified:

• The individual the record is being assigned to
• The individual the record was assigned to before the change of assignment
• The individual who reported the record
• The manager assigned to the current process state of the record
• User Groups within your database

A default set of email rules are configured for each workflow. You can also set the email rules to be set differently based on any pulldown such as Product, Priority, etc. Details on setting your email notification rules can be found in the Workflows Help section.

Tracker can be configured to send email notification messages to unregistered users who submit records via the Submit Page or via email. Details about configuring notifications for unregistered users can be found in this Knowledge Base article.

Alerts

If you have purchased Tracker Enterprise Edition, the Alerts feature is another means of generating email notifications. Alerts are notifications that can be triggered relative to a date field in a record or based on a lack of change of status.

Alerts can be set differently for each individual record if desired. Alerts can also be set based on:

• The form that was used to submit the record
• Which item was selected in a particular pulldown
• The transition used to process the record

• The user who is currently assigned to the record
• The user who reported the record
• The manager assigned to the state of the record when it is added
• Other Users or User Groups within your database

Discussion

If you have purchased Tracker Enterprise Edition, the Discussion feature is a message board or news group feature where your users can have conversations related to a record. These conversations can happen in parallel to the record moving through a workflow. Notification messages can be sent for the following actions:

• Users or user groups can be invited to participate in a discussion via an email notification
• Users can subscribe to discussion threads so that they receive an email notification when a new message is posted to a thread

Create Reports and Configure Preferences

The Home Page reports section is one of the first things a user sees when he/she logs into Tracker. These reports are intended to be a quick snapshot of what's important to the user. For instance, they can show a Developer, QA, Help Desk or Support Engineer which records are assigned to him/her. They can show a manager a chart that shows the status of a project or a list of items being worked on by his/her team. Or, they can show a customer a list of records he/she has reported and tell them the current status of each request.

Tracker has a set of reports available out of the box, such as the "Assigned To Me" and "Reported By Me" reports, but also you are able to create your own reports for personal use or for user groups.

If there are important reports that you want key users groups to use, create them using the information in the Using Saved Queries and Reports section. The Metrics section provides information for creating charts and graphs.

General Preferences

The General Preferences section has some options that can be helpful for guiding users as they use the system. For instance, the Home Page Message in the Home Page Options can be configured to provide general instructions that users will see when they first login (e.g. "Click on the Add icon to submit a request. Click on the Task icon next to a record in the "Assigned To Me" report to process a record assigned to you.").

Review the Help Options to customize tips and make the help descriptions available to your users.

Branding

The Login Page Options section allows you to add your logo and other text by adding custom HTML to the top and bottom of the Login Page.

Configure Add-On Features

Configure any add-on features you have purchased.

Submit via Web for Unregistered Users

Use the information in the Submit Page Help section to configure this feature to allow unregistered users to submit records without logging into Tracker.

Submit via Email

Use the information in the Submit via Email Help section to configure this feature to allow users to submit Tracker records via email.

Knowledge Base

With the Knowledge Base feature, you can publish content that is available outside of Tracker. You can use a formal workflow for drafting, reviewing and publishing articles to the Knowledge Base. An example is described in the Knowledge Base Template section. Or, you can simply publish records to the Knowledge Base without a formal workflow process. Use the information in the Knowledge Base Help section to configure this feature.

Test and Rollout

You should now have a basic configuration that reflects your process(es). Test it out by adding some records and moving them through the process to check whether the necessary data is being gathered at the appropriate steps and the users are being notified as needed as the record is processed. Then, make any necessary adjustments. If you need assistance or have questions about how to address specific issues while implementing the system, contact NetResults Technical Support.