Let's discuss what rules and fields we will need to create.  In part IV  we will discuss an adjustments we might need to make to existing rules we already have.

1. Create Custom Field to Hold Timer Data

The following data needs to be tracked:

• timestamp the ticket was last modified by any ticket change -- this will replace the meaning of our traditional "modified" field. This is necessary because the rules will update the ticket counter periodically which will update the modified time. This means the modified time will now reflect either the last time a rule modified the ticket or the last time a user modified it, whichever is greater.
• The counter(s)* itself. This will track the time the ticket has been in an opened state. If you want to track the total time a ticket has been stalled then you could have a separate counter. And then there are many customers who are interested in the combination of the two which could be obtained by summing them OR modifying the rules to track the combination in one counter. In our example we are going to have one timer to track "total hours opened" and another for "total hours stalled".
• timestamp of when the counter was last updated. This will allow us to keep the timer running efficiently without doing too many calculations through complex queries.

* there are some caveats we'll talk about later.  We are creating 4 custom fields but 5.4 can handle many custom fields so I recommend 5.4

Here is an example of setting up the fields at Service Desk->Configuration->Queues->(pick a queue)->Custom Fields and Layout->Ticket Layout section. 

Note that in the database field CUSTOM_15 is stored as HD_TICKET.CUSTOM_FIELD_VALUE14 because one system starts counting at 1 and the other at 0. You will see this throughout the SQL of the rules.  If you are using different custom fields then you will have to modify the queries in the rules

2. Decide How to Deal with existing Tickets in your helpdesk

If you do not have any tickets in helpdesk queues you want to use this for then this is irrelevant. If you do have helpdesk tickets in this queue then here are your choices:

• Delete all tickets in this queue
• Modify the rules (in SQL) to only act upon tickets above a certain number
• Populate all the existing tickets with baseline data. Running the rule called "Populate Existing Tickets with Baseline Data" will update all existing tickets that have no timers set (which is different then having 0 set)

3. Create Rules to Govern Timers

We need to deal with tickets when they are modified. Tickets can be modified in the GUI, by email and by ticket rules. We need to keep track of all of those possibilities. Here are combination of events we need to deal with respect to status and tickets being modified: OTS=On Ticket Save

We will need a rule for each. We can combine case 3, 5 and 6 into one rule because they all fire at the same time -- "ON TICKET SAVE" AND none of them have a record of a status change but the current status is accurate.

So we need 4 rules to keep track of the timers. We also need a rule for our replacement of the modified field. We can combine that with case 1 since they both run first.

Here are the rules: