There is an action on the Service Request application – Apply Service Request Template, a similar named action is on the Incidents and Problems applications. As the name suggests a ticket template is a template for a common request or incident, when applied it copies over fields to the ticket-based application, in our case to a new Service Request.

Ticket Templates can be used from a Quick Insert portlet on a Start Center and they are also used from the Submit a Service Request Work Center. This article will only focus on applying a ticket template in the Service Request application.

Applying a Ticket Template with Activities

In our first scenario we will use Ticket Template 1005 – Meeting Planner, which we will apply from a Service Request, as if a service desk agent was receiving a call to book a meeting room. The ticket template is against the class of SR (Service Request) and it has a set of four activities. I can hear a few Maximo consultants suggest that Service Requests do not support activities, they do, except visually the Service Requests application does not have an Activities tab, as it does in the Incidents and Problems application.

In the Service Requests application, I’ve created a new service request, it uses the autonumbering and the identifier is 1254. The person calling in to book the meeting room is FRAN which you enter in the Reported By field, but she is calling on behalf of her supervisor ED, who is entered in the Affected Person field. 

At this point I saved the record, the status is NEW, and I then used the action Apply Service Request Template. Notice the Summary field is blank.

The Apply Service Request Template action opens a dialog with columns for the template identifier and the description. You would normally filter in the Description field which would narrow the search sufficiently, in this case I can see Meeting Planner as the third record down, so I will select this and use the OK button.

If the Service Request’s SiteA structural element of a Maximo database that is used for data separation. More attribute has a value (it doesn’t) then the ticket templates selectable are those where the site is within the organization on the ticket template, or where the ticket template organization is null. As the SR Site was null, then all active ticket templates are selectable.

A Ticket Template cannot be applied once the ticket has reached RESOLVED or COMPLETE state or one of their synonyms, you would instead receive error message “BMXAA4311E – The ticket status does not allow for the application of ticket templates.”.

You can see that the description – Meeting Planner – has been copied from the ticket template, as has the Internal Priority of 2. But what about the ticket template activities?

In the Work Order Tracking application, you can use the Advanced Search and search for Originating Record 1254 and Originating Record Class =SR. You may also need to change the Class to allow for both activities and work orders to be fetched, =ACTIVITY,=WORKORDER, if it is filtered to just work orders.

The result is the four activities that belong to the service request 1254, activities T1255 through T1258. You can see that at least the description and priority has been copied from the ticket template’s activities.

Notice, the activities have been created in the BEDFORD site. An activity exists in the work order table and must have a SITEID.

• If the Service Request has a SITEID this is used
• If the Service Request has a null SITEID then the ASSETSITEID is used
• If both the Site and Asset Site are null, then the user’s default insert site is used.

In our case the third bullet was true, MAXADMIN’s default insert site was BEDFORD and the service request had neither a Site nor an Asset Site.

Navigating through to T1255 – Secure Room for Required Number of Attendees, you can see in the Follow-up Work section that the Originating Record was 1254 and Originating Record Class was SR, further down the Owner Group is MTGCOORD copied from the corresponding ticket template activity.

Only one ticket template can be applied to a ticket. If you attempt it a second time, then you will receive the error message “BMXAA4300E – A template has already been applied to this SR”. If you applied the wrong ticket template, then you either close the service request, which if it has been given out to the Reported By person may not be the best choice, or you overwrite the fields which would have been copied from the ticket template with the correct values, deleting the activities if they are not applicable.

The fields which are copied from the Ticket Template through to the Service Request are defined in the crossover domain TKTEMPLATE which is on the hidden attribute TEMPLATEID. It is therefore easy to add other fields to the Ticket Template application and copy them over to the service request. You may need to add to the crossover domain ASSIGNEDOWNERGROUP if you have added that to the ticket template. 

There is no crossover domain on the activities back to the Ticket Template Activities that can be used to modify how data is copied.

When the ticket template is applied:

• The template’s non-null values overwrite existing values on the Service Request
• The service request’s description and long description are not overwritten if they already have a value. The summary may be overwritten if there is a classification with description generation enabled.
• If the ticket template has an organization, then this is set on the service request, it is a hidden field, but it now influences other fields that can be set on the service request, and the service request can only belong to one of the sites of the organization.
• If the ticket template activities contain a Job Plan, then the job plan is applied to the activity, creating tasks, labor, material, services and tool requirements as defined for the job plan.
• If a ticket template activity has a Site, then it will only be copied if the site matches that defined for the Service Request, the site coming from the SITEID, ASSETSITEID or user’s default insert site, in that order.
• If a ticket template activity has an OrganizationA structural element of a Maximo database which is used for data sharing and is often aligned to a legal entity of an organisation. More then it will only be copied if it is the organization on the Service Request (a hidden field), or the organization of the user’s default insert site. 

Incidentally, I like to suggest the TEMPLATEID is added to the service request screen and the advanced search, so that it is easier to check the effectiveness of the ticket templates. 

Applying a Ticket Template with a Classification

In this scenario I wanted to show something to do with classifications that might be a bit unexpected. What happens if a Ticket Template has a classification with one specification attribute and it is then applied to a Service Request? The classification itself has three attributes.

In the Service Request application, I’ve created a new SR 1255 – New employee Andrew Jeffery, with a long description “Please can you onboard the new employee who starts on 2^nd August 2021. He will be working for Danny Bols, he will be home working from the UK.” The request was raised by ED, as it is employee onboarding, I entered Internal Priority 1 and set the Site to WOKING which is in the EAGLEUK organization.

When using the Apply Service Request Template action, I’ve selected the template 1008 – Request for Service, HR, New Employee.

In the Ticket Template application for template 1008 there is an Owner Group of HR, Internal Priority of 1, Service Group of IT and Service of PC with the Classification 2 \ 204 \ 20401. There are four activities.

The ticket template’s specification has just one attribute ALT NAME – Alternate Name, it was an arbitrary choice of attribute to add to the specification.

Back in the Service Request application after the ticket template has been applied, you can see that the Owner Group of HR has been copied over from the ticket template. As an Owner or Owner Group has been applied to the service request there is an automatic status change to QUEUED.

Further down the service request you can see that the Summary field has been modified, this may not be desirable. It is because the classification is set to Generate Description. If you watch carefully after the ticket template is applied the Summary has not been overwritten, but on save the classification’s description generation function kicks-in and changes it.

Other fields from the ticket template have been copied, the Service Group of IT and Service of PC, and the Classification 2 \ 204 \ 20401. 

You might have noticed that both the Summary description and its long description are read-only. This is because the SR application is Edit Mode Enabled in my Maximo environment. If you used the pencil icon in the toolbar (Edit) then the fields become enterable until you navigate through to another record or release the edit mode. 

If we look on the Specifications tab there are four attributes, the first is the ALT NAME that was on the Ticket Template Specification.

If we navigate on the Classification field through to the Classifications application, we can see that the classification has the three other attributes EMPNAME, SUPERVISOR, and WORKLOC.

The attributes from the ticket template are copied to the Service Request, then any additional attributes on the classification that have Use With Object of SR are also copied to the SR. 

• You need to be aware that the classification attributes could come from two sources and not just from the ticket template or the classification.
• If you are modifying the classifications for service requests, you should be aware that any existing attribute on the classification is likely to also exist on a ticket template that references the same classification. If you are deleting the attribute, you may also need to delete the attribute from associated ticket templates. If you are adding a new attribute to the classification, you may consider aligning the associated ticket templates as they will not get updated automatically.

So, what about the ticket template activities?

As the service request site was WOKING the activities were created in the WOKING site as well.

All the data was copied across to the activities as you might expect. The activity T1001 – Create IT Accounts, had a Job Plan IT-ACC-NEW on its ticket template activity, the value has been copied to the activity as can be seen.

On the Plans tab we can see that the four tasks from the job plan IT-ACC-NEW have been created as part of applying the job plan.

When you use the Apply Service Request Template action, it is preferable to have either added a Site to the service request or to have selected an asset or locationA physical place where assets exist and where work can be performed. More or for the asset site field to have been defaulted from the Affected Person’s profile.  Otherwise, the logged in user’s default insert site will be used. If the Service Request is creating activities the site must be derived, and it is better to come from the service request’s site or asset site rather than just being defaulted based on who is logged in and using the action.