Last Updated on November 19, 2022 by maximosecrets

A Ticket Template is what its name suggests, a template for a ticket, similar to a job plan being a template for a work order. A Ticket Template is applied through an action on the Service Requests, Incidents or Problems applications, the three types of ticket. They are also used in the Service Request Work Center and they can be used from a Quick Insert portlet on a user’s Start Center to launch the Self-Service Create Service Request application with the ticket template already applied.

The Ticket Template application is simple to understand. It exists at the System level, the same level as for all ticket-based applications.

The Template Identifier will be auto numbered but some sites do give it a meaning, easier to keep the automatic numbering. Once saved the template identifier will be read-only.

The Description field must be easily understood by end users and service desk users as it is the main field for identifying one service over another. It may be derived from the selection of the Classification if classifications have been set up to generate descriptions.

The Class field is mandatory and is the class of the ticket, SR, INCIDENT or PROBLEM.

The Status field has three states DRAFT, INACTIVE and ACTIVE, DRAFT is the default.

Details Section

Owner Group and Owner work as two mutually exclusive fields, if one has a value the other will be blanked. The Owner Group is defined in the Person Groups application. The Owner Group will direct the incoming service request through to the team that can deal with the request, in the example shown this is the MTGCOORD – Meeting Co-ordinator team. It would be less likely that an incoming request would be set up to direct it to an individual, defined in the Owner field, what if that person was on holiday or on another leave of absence? 

If you do need to set up some ticket templates against an individual then you may consider unhiding the field Assigned Owner Group (ASSIGNEDOWNERGROUP), which identifies the team that the owner belongs that will still be responsible for the service request or incident, in the absence of an individual. 

The Internal Priority defaults onto the same field on the Service Request. The two fields Impact and Urgency can be unhidden and used with a Maximo formula to derive an Internal Priority by using a matrix between the values selected for impact and urgency.

Instructions is a field that is used on the Service Request Work Center to help give guidance to a problem being reported, and it is not copied through to the Service Request. It is the long description field, which is actually displayed, the field that relates to INSTRACTIONS_LONGDESCRIPTION. (Note. The attribute is called INSTRACTIONS and not INSTRUCTIONS.) 

The two fields Service Group and Service are defined in the Service Groups application and are copied onto the Service Request when the ticket template is applied. They define the high-level services being offered to your organisation. They allow you to monitor the requests and work being performed to support the service. You also associate service groups and services with service level agreements (how you measure the service), and with assets, locationsA physical place where assets exist and where work can be performed. More and configuration items that are needed to provide the service.

If you select a Service Group, the Services shown in the Select Value are those that belong to the service group. If you select a Service, the Service Group will be filled automatically.

Service Groups and Services can also be associated with Asset Types, Purchase Contracts and Lease/Rental Contracts.

Service Groups and Services are useful in that they can be used to help relate one service request or incident with another through the actions View Related Records for Service Group and View Related Records for Service. I have already written about this in the article on Service Groups which you can find here http://maximosecrets.com/2020/07/09/service-groups/.

The Select Value in the Vendor field allows a selection of any company type where that company is not marked as a Disqualified Vendor. Selecting a Vendor will set the 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 field.

The Order field is used by the Service Request Work Center to order the services that share the same service classification. It isn’t used as an order in the Ticket Templates application. 

The Classification and its Class Description field below it allows you to search the classification hierarchy for the services you provide or the incidents you deal with. These are set up in the Classifications application with a Use With Object the same as the Class of the ticket template. For example, if the ticket template’s class is SR, then the Classification’s Use With Object would be SR. The selected classification may have a set of attributes which will be copied through to the Specifications tab. Typing into the Class Description or using its Select Value may be the fastest way to find the right classification.

The classification’s attributes are often written as a series of questions related to the classification, which if filled-out will help to narrow the focus of the request or incident. The classification and the values used for the attributes can be used to automatically generate the short description for the ticket template. 

Classifications can exist at the site level, but there is nothing stopping a different site being used, one that is not equal to the classification’s site.  The classification cannot be selected until the Class field has been filled. I would typically save the record after entering the class, then fill out the other fields that are needed.

The Organization field, if set, will be copied to the Service Request when the ticket template is applied, and this would then restrict the set of Sites that can be chosen for the service request.

Activities

A ticket template may contain one or more activities, this is more common with the class of INCIDENT or PROBLEM, but it can also apply to service requests, when the class is set to SR. The standard Service Requests application does not display the activities, but this can be easily modified with a small amount of configuration using Application Designer. The Incidents and Problems application have an Activities tab showing the activities with the Time Tracking table window displayed below this.

When applied to a ticket the activities will become a record in the WORKORDER table with a class of ACTIVITY.

The Sequence field provides the order in which the activities should be performed. The convention is to use 10, 20, 30, etc so as to allow another activity to be entered between.

The Description field may be overwritten if a Job Plan is selected, it would then become read-only. There is a long description which also comes from the job plan.

If you enter a Job Plan Maximo will apply the job plan to the activity, creating any tasks below the activity record. These activities can be viewed in the Work Order Tracking application, except they are normally filtered out. The Advanced Search and Class field can be changed to include =ACTIVITY,=WORKORDER. Activities can also be viewed in the Activities and Tasks application, which many users may find easier to use than Work Order Tracking.

Only active job plans can be selected. Selecting a Job Plan will populate the SiteA structural element of a Maximo database that is used for data separation. More, Organization, Owner Group, Owner, Priority and Description fields from the Job Plan. Apart from the Site and Organization those fields will now be read-only.

The Select Value on the Job Plan field will depend on whether the user has entered an Organization and/or Site first.

• If no Organization or Site, then all active job plans are selectable
• If an Organization and no Site, then all active job plans belonging to the organization or where there is no organization are selectable
• If an Organization and Site are both entered, then all active job plans belonging to the site, or the organization with no site referenced, or job plans with no organization or site are selectable.

The same Job Plan cannot be referenced on multiple activities of the same ticket template, you will receive the error message “BMXAA4277E – Cannot enter duplicate job plans.”.

The Site and Organization fields can be used as a default for the ticket, they also act as a filter for the Select Values of Job Plans and Vendor. Selecting a Site will populate the Organization field. Selecting an Organization first will limit the selection of the Site.

The Owner and Owner Group fields are mutually exclusive, only one of the fields can have a value. There is a hidden field ASSIGNEDOWNERGROUP which is the owner group that the owner belongs to, it would be used when Owner is used to define which team is taking responsibility for the activity.

The Priority field is an integer value which should be in the range 0 to 999 where 999 is high, however, there is no validation on this field, a domain should be configured for it. It is the priority which will become the work priority (WOPRIORITY) on a work order record, and this is restricted between 0 and 999. There is no impact and urgency fields on a ticket template activity.

The Vendor field’s Select Value is filtered by the Organization. If the Organization field is empty, then selecting a vendor record will populate the Organization. Any company type where that company is not marked as a Disqualified Vendor can be selected. 

The Classification and its Class Description field are set up in the Classifications application with a Use With Object of TKTEMPLTACTIVITY. As the ticket template activities will end up in the WORKORDER table when the ticket template is applied to a service request or other ticket, they need also to be defined with a Use With Object of WOACTIVITY, the database view of work orders that shows activities.

The selected classification may have a set of attributes which will be copied through to the Specifications tab. The classification’s attributes are aimed at information to be provided to the team that is managing the activity, points that they need to consider or verify. They can be written as a series of questions related to the activity’s classification, which if filled-out will help to narrow the focus of the request or incident. For example, in an onboarding request there could be an activity to supply a mobile phone and an activity to supply a laptop, the attributes for the phone might include the colour and memory. However, the places in Maximo where a ticket template is applied do not show the activity’s classification/specification and so, if you are going to use this to capture additional data, then some configuration will be needed, for example on the Service Request application.

The classification and the attribute values are not used to generate the short description for the ticket template activity.

Specifications Tab

There is, unusually, two table windows on the Specifications tab. The top table window relates to the classification of the ticket template and will be used on the service request or other ticket. For example, the additional questions asked by the service desk, e.g., a classification of Broken Window, might ask “How high up is the window?”.

The second table window will show all of the attributes of the classifications linked to the activities of the ticket template. Notice the first two columns are the activities Sequence and its Classification. The table window is sorted by the Sequence field, but as each activity’s classification may have multiple attributes then you may wish to extend this with configuration to include the attribute’s display sequence, JPSEQUENCE, DISPLAYSEQUENCE.

Note. On the Self-Service Create Service Request application and the Submit a Service Request Work Center the user only sees the classification attributes that come from the ticket template and not the ticket template activities. 

Change Status

The Change Status action is used to change status from DRAFT to ACTIVE or when a ticket template is no longer required to change status to INACTIVE. Only ACTIVE ticket templates can be selected to create a Service Request. Once a ticket template has changed status from DRAFT to ACTIVE or INACTIVE, it cannot return to DRAFT. An INACTIVE ticket template can be made ACTIVE again. There is a memo field, but there is no history table for status changes, and no place in Maximo where the memo will be stored.

Duplicate

The Duplicate action duplicates both the ticket template and its activities as you might expect. The next autokey value is provided and the status of the new ticket template is DRAFT. In one Maximo system at 7.6.1.2 I did receive the error “BMXAA6713E – The MBO fetch operation failed in the mboset with the SQL error code 933. The record could not be retrieved from the database. See the log file for more details about the error.” which prevented the duplicate record from being saved. This was corrected if I changed the Order field. I couldn’t replicate it on IFIX010 for Maximo 7.6.1.2. 

Delete

The Delete action deletes the ticket template and activities, and can be used at any status.