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

Projects are created in the Projects section. 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 item. 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.

When creating a new project, you will have the option to select an existing form to be associated with the new project. Selecting a form is not required (select <None> if you have not yet created the Form you want to use). If you have selected a form, you can also select the Workflow that should be used by the Form in this Project.

When creating new projects, keep in mind that each user needs to be a member of a user group that has access to at least one project in order to be able to login to Tracker.

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.

Forms are created in the Forms section. 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 Fields section.

If the workgroup is created using a SQL Server or Oracle database and you are using multiple forms, cross-form metrics 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.

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

When creating a form, you will have the option to select whether the form will be used with a Workflow. If you never intend to use a Workflow (states, transitions, automatic assignment and email notifications) with the form, select "No" for the Used in Workflow option. Selecting No will set all of the system-required fields (Product, Status, Reported By, Assignee) such that they are not visible to non-Admin users on the form being created. Select "Yes" for the Used in Workflow option if you ever intend to use this form with a Workflow. A Workflow allows you to set up states, transitions, automatic assignment and email notifications when records are submitted using the form. When "Yes" is selected for the Used in Workflow field, the Workflow field contains a list of available workflows that can be associated with the form you are creating. Select a Workflow for the Form. If you do not wish to select an existing workflow (e.g. you plan to create one for this form at a later time), you can select "Empty Workflow". Empty Workflow is a Workflow that has only one state called "Not Applicable", has no transitions or email rules and has TBD as a state manager for the "Not Applicable" state (the state manager cannot be changed). If you wish to create a new workflow for the form you are adding, select the "<Create New Workflow>" option.

Fields

Select which existing fields should be available on each Form via the Forms section. Every form will have the system required fields: PRN, Status, Reported By, Assigned To, Deleted and Product. These fields cannot be removed from any form. They can, however, be made so that they are not visible to any groups using the Field Visibility settings for each field. If No was selected for "Used In Workflow" option for the form, the fields Assignee, Status, Reported By and Product will be hidden on that form for all user groups (including the Admin user group).

Create any other fields that will be needed for each form. Fields can added to more than one form. Fields are added in the Fields section. After adding a field, you will have the option to select which forms in which the new field will appear.

When deciding which fields you need, 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. For example, if you want to be able to track when a record was closed, you will want to have a "Close Date" field available for this piece of data to be captured.

Other questions that can help you identify the fields you need and the properties they should have are:

• What data type should the field be? For example, you could 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 would prevent users from typing in different versions of the same choice and would make running reports simpler.
• Where should this field be displayed? You can choose whether each field is displayed on the Add, Submit, Edit and View Pages, Query and Home Page reports and email notifications.
• 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.
• If you are using multiple forms, will you need to link records created with one form to records created using another form? For example, let's say you have created a form for submitting support issues and another form for submitting development issues. You may want to be able to identify support issues that are related to development issues and vice versa. You can use Link fields to associate records of one form to another.

The next section provides information for creating Workflows.