Status Track

Status Track is used for tracking changes in a Ticket without relying on the users themselves to record such information.

To change the Status of a Ticket, a function must be used (not simply by editing the Status field). The scope of this function may vary according to the Status being set. For instance, the function to close a Ticket will also need to calculate some End-date information. Every function that changes a status however, also protocols the status change itself.

• Each Status change is recorded in its own Ticket Description. The new status is recorded together with the name of the person who carried out the status change, and the date and time. This ensures that the responsibility for a Ticket is always known. If a person passes a Ticket on, they have a record of exactly when they did so. If the person to whom the Ticket is passed on does not work on the Ticket immediately, this is also clear from the Date / Time information. This information can be relevant for Service Level Agreements where e.g. work must start on a Ticket within a specified period of time.

• The configuration of the Status Tracking Ticket Description is specified in the Status Track catalogue. Here the different Status values are listed and the Ticket Description that should be generated for the Ticket when this status is set is described.

In accordance with the ITIL philosophy, different Ticket Classes have different processes and thus also status values and actions associated with them. There follows a list of Ticket Classes and associated Status values. This list is an indication of the possible kind of structure (it is NOT necessarily complete):

• Incident

  Created, Closed, In Progress, Assigned to, Solved

• Problem

  Classified, Prioritized, Assigned To, In Progress, Analyzed, Approved, Confirmed, Solved, Declined, Completed.

• Change

  Planned, Tested, Approved, Declined, Implementation Scheduled, Implemented Failed, Implemented, Backout Implemented, Backout Failed, Completed.

• Known Error

  Identified, SL Proposed, SL Approved, SL Confirmed, WA Proposed, WA Prepared, WA Tested, Released 2nd, Released1st, Released, Revoked, Retired.

• Service Request

  Classified, Prioritized, Assigned To, In Progress, Executed, Informed, Confirmed, Completed.

• Request For Change

  Created, Registered, Accepted, Categorized, Declined, Approved, Confirmed, Implemented, Implementation Failed, PIR Successful, PIR Not Successful, Backout Implemented, Backout Failed.

• Call

  Created, Classified, Prioritized, Closed

Parametrization of the Ticket Description

It is often desirable for the Ticket Description to automatically list the name of the currently logged user or the name of the original Support Group. On that account, the ticket description can be parametrized in the following way:

• %getAssociatedPerson().fullname%

  The currently logged person will be filled in automatically in the Ticket Description.

• %getOriginalSG().supportgroup%

  The originally assigned Support Group will be entered automatically in the Ticket Description. The original Support Group is the Support Group which had been assigned before the status action was launched.

Example:

Ticket Description in the 'IN_SLV' (Incident Solved) status has been parametrized in such a manner so as to automatically fill in the currently logged person and the original Support Group.

The actual notation looks like this: DE: wurde gelöst durch / EN: was solved by %getOriginalSG().supportgroup%%, getAssociatedPerson().fullname%

The eventual Ticket Description will be: DE: wurde gelöst durch / EN: was solved by INCIDENT MANAGER, Mr.Martin Dittmann

Note: The comma in the middle of the notation stands for a conditional separator. The separator will be inserted if the value of the subsequent function will be non-NULL.

Status in the Edit View

Open the Status Track Catalog and you can see different Status values listed. With each status change, a ticket description gets generated. Each status definition thus also contains data that will be used for such ticket description.

The following attributes are displayed:

• Status

  The value of the Status field. The Ticket Description specified in this Edit View will be generated whenever this status function is called.

• Statement Type

  The Statement Type for the Ticket Description. A Statement Type of Protocol or History would be appropriate for all Status Tracking Ticket Descriptions.

• Ticket Shorttext

  This is the Ticket Description shorttext for the Status Tracking Ticket Description. Typically it should state that the Status function has been called. In this example the shorttext "was completed" will be used in combination with the Ticket number. See below for an example of the result.

• Reference 1 Type

  This specifies the Object Type which will be referenced in the first Reference in the Ticket Description. For Status Tracking Ticket Descriptions it is a good idea to use the Ticket number as the reference. Thus the Object Type Ticket is used as the Reference 1 Type.

• Reference 1 Function

  This is the identifying Value of the Object Type specified in Reference 1 Type, in this case a Ticket number. Since the Ticket number is unique, there is a function provided to write the Ticket number into the Ticket Description. Similar functions are also provided for Person or Support Group, which are ideal for use with Pass On or Accept functions. This generates a Ticket Description, which contains the Ticket number, and the text "was completed".

• Reference 2 Type

  The functionality is identical to that which is described for Reference 1 Type.

• Reference 2 Function

  The functionality is identical to that which is described for Reference 1 Function.

• Description

  An extra description of the Status Change, where required.

• Solution

  Marks this Activity as a solution. This marker can be set to flag a solution that may be of interest to others. The Knowledgebase search can be used to search for Activities that have the Solution marker set.

• Report

  If checked, it can be used for reporting purpose

• General Visibility

  With this checkbox it can be controlled if the change initiator is informed about this activity.

NOTE: Functions which change a Ticket from one Status value to another are called Status Transitions. In Valuemation, they are flexible and configurable. This means it is possible to implement rules, which reflect the business practices in the enterprise. There are several catalogs involved in configuring the Status Transitions, however, this is already a matter of a professional customization.