A Ticket Template can be manually applied to a Service Request, Incident or Problem through the actions Apply Service Request Template, Apply Incident Template or Apply Problem Template respectively. A dialog opens allowing you to choose the appropriate template for the class of ticket, SR, INCIDENT, PROBLEM. If you have many ticket templates, then finding the right one might be a bit slow. How can you automate applying the correct Ticket Template?

This article shows you how this is possible using a Crossover Domain.

I’ve created a new Service Request 1275 which has been reported by Fran Garcia (FRAN) on behalf of Ed Adams (ED). This is the same scenario as you will find in the article New Service Request which you can find here – http://maximosecrets.com/2021/10/12/new-service-requests/.

I haven’t saved yet, but you can see that the status is at QUEUED and it will be directed towards the Owner Group team of OFFICE, this is a Person Group. Both changes are a result of automatically applying a Ticket Template.

In the Service Request Details section I selected the Classification 2 \ 201 \ 20102 \ 2010205 – Request For Service \ IT \ New Upgr Sftw \ Other and this generated the short description, the Summary field. This uses the description generation function which is part of the Classifications application.

The fields for Internal Priority (3), Service Group (IT) and Service (SUPPLYCH) have all come from the applied Ticket Template.

When I saved Service Request 1275, it remains in Edit Mode, you can see the green pencil icon in the toolbar. This means that no other member of the Service Desk team will be able to make changes until Mike Wilson releases it. You can read about Edit Mode in this article – http://maximosecrets.com/2021/10/11/edit-mode/.

Notice that the View History dialog shows that there was no NEW status. If you are going to adopt using this method, then you need to make sure that any KPIs or Reports are not expecting a NEW status to exist.

The Ownership History record was written when the service request was saved, on 12^th October 2021 at 12:06. The Reported Date was the same day at 11:52, the date and time at which the New Service Request button was used. The QUEUED status occurred at 11:53, the time the Ticket Template was applied.

If we have a look at Ticket Template 1013, we can see that it has the same field values for Internal Priority (3), Service Group (IT) and Service (SUPPLYCH), and that the Owner Group is set to OFFICE.

The Classification 2 \ 201 \ 20102 \ 2010205 – Request For Service \ IT \ New Upgr Sftw \ Other is a match to that entered on Service Request 1275.

In Database Configuration I’ve added a new crossover domain CLASS2TKT to the CLASSSTRUCTUREID on the SR object. I could have added this to the TICKET object to have it applied the same way on other types of tickets.

In the Domains application a crossover domain CLASS2TKT was created against the TKTEMPLATE object, the main object of a Ticket Template. It finds a Ticket Template where the CLASSSTRUCTUREID is the same as the one being entered on the Service Request and copies the primary key field TEMPLATEID to the same attribute on the Service Request. The CLASSSTRUCTUREID is the key field of a classification hierarchy. 

The No Overwrite flag for the TEMPLATEID attribute is set so that if the Ticket Template had already been applied to the Service Request it wouldn’t attempt to set it again. However, you might find that you wish is to be changed or changed based on a condition, you would need to work this out as part of an implementation, considering all the ways in which the Ticket Template is applied to a Service Request.

Notice that this crossover domain is not copying the attributes for Internal Priority, Service Group, Service, and Owner Group.

The TEMPLATEID attribute on the SR object already has a crossover domain TKTEMPLATE. 

This is an example of a set of chained crossover domains, the new CLASS2TKT domain fires and causes the TKTEMPLATE domain to also fire, a chain reaction.

It is the standard TKTEMPLATE crossover domain that copies the attributes from the Ticket Template to the Service Request. The COMMODITY and COMMODITYGROUP that you can see are the Service and Service Group fields. Other fields copied are Impact, Urgency, Internal Priority, Owner, Owner Group, Vendor and the ClassStructure Identifier. The eagle-eyed of the readers might be thinking why I have missed out a set of fields, 13 attributes are in the crossover domain, the others happen to be part of the HSE applications.

Caveat – You do need to test this thoroughly using all the sources of creating a Service Request with a classification, and whether the ticket template is applied first before the classification. You may need to use conditions on the Crossover Fields. If I were aiming to use this in a production environment, I would be verifying a set of tests with SQL logging to make sure that no looping is occurring between the two crossover domains. You should also consider what happens if the Classification is changed, as you cannot apply another Ticket Template if a Ticket Template already exists. You also need to bear in mind, if using the Incidents and Problems application that they can share the same ClassStructure Identifier, but they would have a different Ticket Template. 

Note. The use of the crossover domain is based on a one-to-one relationship between a classification and a ticket template, this will work for many Maximo clients, and it is a good starting point for all clients. For Service Providers the relationship may be different as a classification may be specific to one or more customers. For clients using Maximo for Service Providers (or IBM Control Desk) I would recommend using Response Plans as this provides greater flexibility.