KLA's technical support staff have an operation time of 24×7 at Ford and need a system that will automatically escalte untouched tickets to a primary and a secondary on-call staff member.

The escalation process is to be able to send a text and email to the primary on-call after 30 mins of a ticket's inactivity. After an additional 30 minutes,

Every time a ticket is created in the Ticketer, in the 'SNMP Trap' with the start state 'Alarm Received'. The 'IDMS Ticket Grouping' Groovlet executes to calculate various SLA metrics for that ticket. In this Groovlet is where the Ticket Escalation process is also scripted.

As soon as non-child ticket enter's the 'Alarm Received' state, the ticket escalation process creates a number of 'Persisted Tasks' to track this ticket. Each Persisted Task contains a closure that executes after a specified time interval, and when executed after the defined duration of time, it checks if the tracked ticket is still in a certain state and if it is still in the escalation time, if so it sends escalations(Email & SMS) to KLA's various tech support tiers.

KLA doesn't change the contact details with each level of priority.

Escalation process also considers priority changing by more (child) ticket in same network identifier, by removing the current tasks on the priority updated parent ticket and assign them a new task.

• Level 1 Escalation: A ticket in alarm received 30 mins → Email and SMS to all primary users

• Level 2 Escalation: A ticket in alarm received 1 Hour → Email and SMS to all secondary users

• All Tickets are escalated 24 hours a day, 7 Days a week

When the escalation process was created, there needed to be a mechanism to allow KLA simply change to contact details of the On-Call primary and secondary Tech Support Engineers. This escalation level will vary. In order to support this and not have hard-coded contact details in the script, a number of place-holder users where created in the ticketer(see below).

The Ticket Escalation process keys of off each of these placeholder users in the Ticketer. It uses the contact details in each of these users to send Email and SMS. The key fields used in each user are highlighted below.

Email templates are also used when sending Email escalation, the Ticket escalation process looks up the appropriate email template for a given escalation level e.g Level 1, 2, 3 or 4. The email templates used are shown in the below screenshot.

Ticket reported by as not having escalated First thing to check is that the ticket was created in the escalation time-frame, a ticket won't escalate even if it is created one second outside of the escalation timeframe. If the ticket was created in the escalation timeframe, check the priority of the ticket at the time of creation and see if it is eligible for escalation. For example, a customer reports a ticket was created at 02:00 am on Wednesday morning which did not escalate. If the ticket was a priority 3 ticket, these tickets are not escalated outside of the weekend.

Query To Check If A Ticket Should Have Escalated

SELECT
	t.*,
    ts.status,
	ts.status_duration_in_seconds
FROM
	ticketer.ticket t
	JOIN ticketer.ticket_status ts ON t.id	= ts.ticket_id
WHERE 
	ts.`status` = 'Alarm Received'
	AND t.priority in (1,2)
        AND ts.status_duration_in_seconds >= 3600 -- 1 Hour Duration In State 
	AND t.create_date BETWEEN '2018-06-26 20:00:00' AND '2018-06-27 07:00:00';

Currently the string closure in the escalation Groovlet logic is at max character capacity, all whitespace has been removed and tabs etc to fit the required logic into the Persisted Task, please be aware of this when making changes. A development request will need to be actioned as this is a domain class and cannot be edited directly in the database as Grails still enforces the constraint at runtime even though the column has been altered at the DB level