Take a Number

The Information Technology Infrastructure Library (ITIL) [1] which was developed back in the 1980s, has established itself in recent years as the standard for IT Service Management (ITSM). One of the most important functions within the ITIL framework is the service desk – the central and single point of contact for all users. Along with some major, commercial ITIL software suites, open source systems are also available – OTRS [2] and RT: Request Tracker [3], which can manage a range of business and support processes. In this article, I'll concentrate on RT.

Everything in Place

RT offers all the functions you need to operate a tracking system out of the box, including: acceptance and identification of email or other queries, allocation of priorities, assignment of tickets to processing staff, notification of the original requester, and final closing of the query at the end of the process. Although most customers and end users will use email to communicate with the application, the help desk staff can rely on a clear-cut web interface that has been translated into more than 30 languages (Figure 1).

The source code of the current 3.8.8 version of RT is available from the vendor's website and is licensed under the GNU GPL. Manual installation of the software is definitely not trivial. Besides a web server and database, you also need a large number of Perl modules, some of which have to be installed manually. Request Tracker is available in many Linux distributions via the internal package management system, and Ubuntu even has the latest version. On the database front, RT supports classic MySQL, but also PostgreSQL and Oracle.

After completing the installation and the basic configuration in the RT configuration file, you can practically set up the rest of the tool in the web interface, such as the queues where the individual tickets are processed. Many other settings, such as user privileges, email templates, or additional fields, are then typically configured individually for each of these queues, although you can create items globally for the system. In fact, the administrator just needs a quick visit to the console to connect to the mail server, because incoming mail is accepted by the local rt-mailgate program and forwarded to Request Tracker. You need to configure this program and set all the required parameters as the receiver on your local mail server.

After doing so, end users can use email to send requests and error messages to the ticket system. If the system is configured to do so, end users will receive an automated response with the ticket number assigned to the case and an explanation of the next steps. Request Tracker always creates individual tickets from the messages it receives and then displays them in the unowned tickets area of the web interface.

Depending on the required workflow, help desk staff will either pick up the tickets themselves, or the tickets will be assigned by a dispatcher on the basis of subject and current staff workloads. Help staff can then use the tool to ask questions that will give tips on troubleshooting the problem. The tool logs all of the processing steps and stores them in the processing history along with the timestamps. This means that, if a member of the help desk becomes ill, or has to pass on a case to someone else, the new case manager can immediately see what has been discussed or completed up to that point.

Tickets and Queues

Tickets include a number of properties in fields, which in turn are subdivided into various groups and displayed in the header area of the ticket. The individual categories can be hidden or displayed, and they are color coded for easy identification (Figure 2).

The tab labeled The Basics contains the basic properties of the tickets, such as ticket number, current status, the initial and final priorities, and the queue to which the ticket was assigned. The People area contains details on the individual people associated with the ticket. They are the Requestor, that is the person or the email address that originally created the ticket, and the current ticket Owner, that is the person who is responsible for processing and, above all, signing off on the ticket.

Also, you can add other people (called "watchers") to the ticket as either Cc or AdminCc. Just like carbon copy recipients of an email, these people receive copies of ticket correspondence with varying levels of detail. The administrator will typically want to configure the system so external people are added as Ccs and handled in the same way as the requester, whereas internal staff are added to the ticket as AdminCcs. The big difference lies in the configuration of the workflow later. Ccs only receive normal correspondence, whereas AdminCcs also receive internal comments. Thus, you can correspond with your customers and your colleagues within a single ticket, without the customer receiving internal and possibly confidential comments.

The various date fields are located in the Dates panel. Although Created, Closed, and Updated are set automatically, you can manually configure Starts, Started, Last Contact, and Due. The date fields merely serve to calculate deadlines, such as Created 4 weeks ago, or to compute response times for reporting purposes. This data also supports precise monitoring and evaluation of service levels.

Links between various tickets are another organizational function in Request Tracker. You can use this feature to model dependencies between various tasks in the Links panel. The relationship types are Depends on, Parents, Children, and Refers to. If you set a relationship of the kind "ticket nine is the parent of ticket three," the corresponding relationship will automatically be set in the opposite direction, that is, "ticket three is the child of ticket nine."

On the basis of these relationships, you can introduce logical rules into the ticket system. For example, a ticket that depends on other tickets cannot be signed off until the other tickets have also been signed off. Request Tracker can visualize these dependencies across multiple levels and thus create dependency graphics from the ticket data (Figure 3). To remind yourself or another user of an important deadline, you can create reminders for tickets, which are then displayed on the start page or dispatched by email.

Besides the basic data, Request Tracker also records a complete processing history, including time stamps and any fields that have been modified. This history is displayed after the metadata for any ticket (Figure 4). To keep the system auditable, there is no option for deleting or manipulating transactions in the web interface. Of course, the user can modify nearly any value of the ticket, but the system will always create a transaction register detailing who modified which data and when.

The various queues are used for processing tickets; they are normally organized by topic, department, or process. Queues can possess their own email addresses, priorities, and deadlines.

Permissions are also configured in a queue-specific manner. This means that you can define precisely which department can view, modify, and possibly even delete the tickets. These settings can be defined for users, user groups, and roles.

For each queue, the admin can configure individual watchers to automatically receive Cc copies on the correspondence without needing to set this up individually for each ticket. For example, a team leader can be notified of all the actions that occur within their department. The workflows and custom fields described in the following section are also configured in a queue-specific manner.

Workflow Structure

All automated actions in Request Tracker are controlled by an internal scripting engine. The corresponding rules are referred to as scrips [4], which is a play on the terms "script" and "subscription." A rule always comprises three parts: condition, action, and template. To set this up, you need to state which event will trigger an action as the condition. Examples of such events are On Create, On Resolve, On Owner Change, On Priority Change, On Status Change, and On Comment.

The second setting, Action, defines the action that will be triggered when an event occurs. Examples of this are email messages, such as Autoreply to Requestor, Notify Owner, Notify AdminCCs as Comment, or various ticket actions, such as Open Ticket, Resolve Ticket, or Create Ticket.

The third setting, Template, defines the template to be used when executing action. The template can be an email template or a template for a new ticket. Within these templates, all the properties of the ticket can be used as variables. Request Tracker will then replace them later – with the live data from the ticket in question – when a scrip is executed (see Listing 1).

01 Subject: [{$rtname} #{$Ticket->id()}] Ticket closed!
02
03 We have resolved and closed the following ticket:
04
05      Ticket: [{$rtname} #{$Ticket->id()}]
06       Queue: {$Ticket->QueueObj->Name}
07     Subject: {$Ticket->Subject || "(No subject given)"}
08       Owner: {$Ticket->OwnerObj->Name}
09   Requestor: {$Ticket->Requestors->EmailsAsString()}
10  Ticket URL: {$RT::WebURL}Ticket/Display.html?id={$Ticket->id}
11
12 Please check the content. If everything turns out to your
13 satisfaction, no further action is required. If the problem
14 still exists, please respond to this email: in this case a
15 ticket will be automatically reopened. Thank you.

As you can see in Listing 1, users will receive an automatic response when they address a query to the help desk by mail. This reply fulfills several functions: It informs the user that his query has been received, and the user receives information on the newly created ticket and possibly on the outstanding process steps. This behavior can be configured using:

Condition: On Create
Action: Autoreply to Requestor
Template: Autoreply Template

The scrip mechanism makes it possible to configure and automate Request Tracker and its processes in a way that allows for highly granular configuration of the complete correspondence logic – that is, what happens when mail arrives, what outgoing mail looks like, and which actions are triggered by mail. Scrips also can be used to control behavior within Request Tracker. For example, when a ticket is closed in one queue, another ticket can be created automatically in another queue – for example, to support quality assurance after signing off a project.

Besides predefined events and actions, you also can create versions specific to a particular user. Because Request Tracker was written in Perl, self-defined scrips are created in Perl syntax.

Listing 2 shows a user-defined action that always occurs when a ticket is created. The scrip checks the sender address for the @customer.com pattern. If this domain name occurs in the address, an additional email address, helpdesk@customer.com is added as the Cc recipient of the ticket. That way, the customer's help desk always receives a copy of every email. This type of functionality allows many manual tasks to be automated within the ticket system.

01 if ($self->TicketObj->RequestorAddresses =~ m/lc\@customer\.com/) {
02   $RT::Logger->error("Add Helpdesk Address");
03   $self->TicketObj->AddWatcher(Type => 'Cc', Email=> 'helpdesk@customer.com');
04 }

Classifying Tickets with Custom Fields

Another, very powerful function in Request Tracker is its custom fields, which the administrator manages via a separate menu item in the configuration menu. Besides tickets, custom fields can be created for queues, user groups, users, and even ticket transactions. Request Tracker supports different types of custom fields, such as, drop-down lists with simple and multiple selections, simple text fields, complex fields that use CamelCase, and upload fields for attachments. The fields can have predefined selection options, perform validity checks, or support completely free-form input options.

Administrators can add a custom field to one or multiple queues. The custom field will exist only for the tickets in these queues. For example, it only makes sense to specify a printer name if the corresponding ticket is in the queue for printer problems. You can assign user permissions for the individual custom fields. This gives you the ability to define precisely which users or groups can view, modify, or manage properties of individual custom fields.

Custom fields can also be used in the scope of workflows. For example, a release can only be issued by a release manager. Other users might be able to see the field, but they do not have the permissions needed to modify it.

When the release manager modifies the status field, the workflow engine automatically releases a corresponding change.

Reporting

An integrated reporting system provides the ability to generate and visualize various statistics. For example, if you need a monthly report, you would first define the required search criteria for evaluation, such as "all processed tickets in the request fulfillment queue that were created in the past month." You can also store the search criteria to avoid having to create it once again next month.

The user can then display and evaluate the results as a ticket list to see, for example, which user created the tickets, and you can even use custom fields for this. For example, if you have a license field, you can identify the number of software licenses (Figure 5).

Customizing and Extensions

As I mentioned previously, RT adapts well to the specific needs of an organization, but you can also modify individual users or roles. This task is typically done by configuring queues, workflows, and custom fields, but even the web interface is customizable in many respects. For example, users can create individual dashboards for special tasks next to the dashboard on the start page.

A user who acts as a change manager needs a different view of the tickets than somebody on the help desk. On their Change Management dashboard, this user can view tickets from other areas, too. Additionally, the view and structuring of the tickets is not organized by queue, but by process status. For example, the tickets could be organized into those with changes that still need to be approved, those with changes that are waiting for implementation, and those with changes that have been implemented but still need to be released.

Besides these configuration options, RT offers many other tools and settings that make the administrator's life easier. For example, you can publish searches or entire queues as an RSS feed. Colleagues can subscribe to the feed and thus keep track of important changes without needing to receive all the email messages for the ticket in question.

The RSS feed can also be used to integrate information from the ticket system with other media, such as a wiki or website. Because it uses the iCalendar format, ticket information can also be integrated with the calendar. Users can process a large number of similar tickets at the same time via bulk operations – for example, to transfer all higher priority tickets to a colleague if an administrator is sick. Changes can even be implemented offline by saving the ticket data in a text file and then importing the data back into RT after making changes. A mobile Request Tracker interface is also available to improve processing on cells and smartphones.

Features that go beyond the normal functional scope can be added retrospectively as RT Extensions [5]. The long list in the RT wiki includes a graphical workflow builder, as well as various packages for statistics and reports or for mapping and managing Service Level Agreements. With a little Perl know-how, administrators can make changes to Request Tracker themselves and write their own modules. The modules can be clearly separated from the standard program code and can thus be used after an update without having to modify the source code every time a new version is deployed.

Conclusions

Request Tracker is a very well implemented and powerful open source tracking system that administrators should take a close look at. The software has been under active development for years, and the mailing lists offer excellent support. Because of its rich feature set, open architecture, and ability to customize, Request Tracker rewards the user with almost unlimited deployment and extension options, after a manageable learning curve.