In the article on Self-Service Service Request, user REDDING submitted a new service request 1273, the conference room he uses was found to be too hot. We’ll start by examining that service request from a service desk agents view, with user WILSON. Later, we’ll create a new service request from scratch in the Service Request application.
You can find the article here – http://maximosecrets.com/2021/10/01/self-service-service-requests/
This article covers the fields down to and including those in the Service Request Details section, the fields that a service desk agent is most likely to use when recording a new Service Request. I’ll be covering other fields, tabs and actions in other articles.
This article includes:
- Reviewing a Self-Service Service Request
- A New Service Request
- Organizations – Autonumber Setup – System Level
- User Information
- Service Request Details
- Asset and Location Select Values
- Asset and Location Defaulting Rules
- Ticket Classifications
- Ticket Priorities
- Ticket Service Groups and Services
- Address Information
Reviewing a Self-Service Service Request
Service Request 1273 is at the initial status of NEW. The Service Address has been derived from the location hierarchy it was not entered by the user.
In the User Information section, we can see the user who reported the issue, REDDING, their name, phone and E-mail, and there are a set of similar fields for the Affected Person.
Further down the screen the Summary field was derived by using the description generation function associated with the entry of a classification. The details were entered by user REDDING, as was the location, CONF400 – Conference Room #400. The GL Account and Asset Site were both derived from the selected location. The Reported Priority of 2 (High) was selected by REDDING.
At the bottom of the main tab of the Service Requests application we have three sections of fields. In the Dates section the Reported Date was that defaulted on the Self-Service Service Request application. The Affected Date is defaulted to the date/time the record was saved to the database; it doesn’t appear on the self-service application. The reason for the time difference between the Reported Date and Affected Date was simply because I started the article on one day and finished it the next, normally there would only be a minute or two between those two date fields.
As you can see there are quite a few fields to go through, I’ll explain some of these as part of this article, but it will take several articles to cover the whole of the Service Request application.
Did you notice that all fields are read-only? This is because Edit Mode has been enabled for the Service Request application where multiple Service Desk agents may be trying to update the same record. The user will need to use the pencil button in the toolbar to toggle Edit Mode on/off, so that they can modify the record. You can read about the Edit Mode function in this article – http://maximosecrets.com/2021/10/11/edit-mode/ .
A New Service Request
We will now create a new service request from the Service Requests application and describe each of the fields at the top of the application, down to and including the section called Service Request Details.
The Owner and Owner Group fields are described in a separate article on the two actions that populate these fields Take Ownership and Select Owner – https://maximosecrets.com/2021/10/11/take-ownership-and-select-owner%EF%BF%BC/
In the Service Requests application when a new service request is inserted, it is normal for it to be auto-keyed. In this example the new Service Requests button has created Service Request 1274.
The service request identifier (TICKETID) can be changed before the record is saved, but that would be unusual. If there is no save and the record is discarded, then there will not be a contiguous set of records, the previous number is lost and would not be reused. Autokeys do not provide a contiguous set of records in Maximo, it is how it works.
When a new Service Request is created, the status is set to NEW. Further down the screen (not shown), the Reported Date is set to the date/time when the insert button is used and not the time when you first save the record. The Reported Date can also be modified after the record has been saved. The first status history record, the record associated with the status of NEW, has the time at which the record was first inserted.
There are two hidden fields which record the person of the user who made the last change, CHANGEBY, and the date/time of this change CHANGEDATE. In this case I am logged in as WILSON – Mike Wilson.
A Service Request is defined at the SYSTEM level so that a centralised service desk is made possible. The Site field is further down the main screen and would be needed before being able to apply a Service Level Agreement (SLA) or create a follow-up work order.
Organizations – Autonumber Setup – System Level
A Service Request is a type of Ticket, it is based on a view of the TICKET table where the CLASS=’SR’. The unique index of a ticket is CLASS, TICKETID. Incidents and Problems are the two other default ticket classes but if you are using other industry solutions or the Health, Safety and Environment Manager (HSE) you may also find others, Defects and Investigations for example.
In the Organizations application and the Autonumber Setup – System Level action, the Service Request has a different autokey from Incident and Problem. If using all three applications, it would be quite normal to add a prefix for each Autonumber Name:
- SR for SRID
- IN for INCIDENTID
- PR for PROBLEMID
Incidentally, the Health, Safety and Environment Manager (HSE) add-on gives access to the original Incident, Problem, Solutions, Change and Release applications which were part of the original ITIL (IT Information Library) based applications.
I will return to the Address Information section later.
The User Information section has two columns of fields for the person reporting the request and the person affected by the request or experiencing the issue. By default, these are both filled by the logged-in user, the same as it is on the Self-Service Service Request. But they can both be changed.
The Reported By field must contain a value for an active person, but it can be left blank. An active person is someone defined in the People application with a status of ACTIVE or one of its synonyms, the other person status is INACTIVE.
When a person has been selected then the Name, Phone and Email fields are copied from the fields on the Person record found in the People application. The name is the display name on the person record and the phone and email are those from the primary records, a person can have multiple phone or email addresses, only one of each is marked as primary.
If you do not believe this person has called the service desk previously you can enter the name given by the caller in the Name field. If Maximo finds a person by that name all the fields will be filled from the Person record, as if you had entered a value in the Reported By field. If no person is found or there are multiple people with the name entered, for example you just entered “Mike”, then a dialog opens with the options found as Person records. If you then use the Continue button whatever you typed will be left and you are free to enter a phone and email address as free text. This allows you to create a service request against a caller who has never been registered with a Person record in Maximo.
As a Service Desk agent after taking the call you may wish to check there is no Person record, and if verified save the details so that they can be more easily recalled next time.
If you want to check by part of the name then add the % wildcard in front, Maximo will place the % wildcard at the end of the search string. For example, %Jeffery, actually performs a search of %Jeffery%, i.e., anyone with jeffery in their name.
In this scenario I made FRAN the Reported By person, who was making the service request on behalf of ED her supervisor, the Affected Person.
Both the Reported By and Affected Person fields have a detail menu which includes the action View Tickets and WOs. This allows the service desk agent to view previous tickets and work orders from that person and is one of the ways that a service request can be related to another ticket or work order record, and I will return to this in a separate article, Relating Tickets and Work Orders.
Service Request Details
In the Service Request Details section the Summary field has a long description which is what you see in the Details below the Summary field. The long description has the rich-text formatting toolbar, and it can contain embedded images, for example a screenshot. By default, the shorter description (Summary) is defined as ALN 100.
The Asset field has the same detail menu as found in the Work Order Tracking application, a Select Value, Open Drilldown, Classification and Attribute search, and Go To Assets.
The Location field has the same detail menu as found in the Work Order Tracking application, a Select Value, Open Drilldown, Classification and Attribute search, and Go To Locations.
Once the asset or location fields have been populated you can use the detail menu to View Contracts or View Work Details. On the asset field you can also View Asset Details which will provide a view onto the asset’s classification attributes, its specification.
For most Maximo clients the next two fields are unlikely to be used. They are mostly used by a service desk taking IT calls, but some highly regulated clients do perform change and configuration management in Maximo, and they may find a use for them.
- A Configuration Item (CI) is used in a configuration management database (CMDB) to represent any component that is managed to provide an IT service. For example, a database server, which may have related CIs of the server hardware, its operating system and the database software.
- Target Description is a temporary description field for CIs that have not yet been formally added to the CMDB, perhaps because they are used in Development environments.
The GL Account will be defaulted from the Location’s GL Account and then segments may be overwritten or added to from the GL Account of the Asset.
The Asset Site field is defaulted from the Affected Person’s record and their setting for Person’s Site in the Employee Information section in the People application. It has an influence on the Asset and Location Select Values.
Asset and Location Select Value
The Asset and Location fields Select Value action will filter using the User/Custodian relationship by default. An Asset (or Location) can have multiple people associated with it, this is made by using the Associate Users and Custodians action in the Assets and Locations application.
You can search by either:
- User/Custodian – the User and Custodian fields are filled by the Affected Person, but they can be changed or one of them blanked and then when the Refresh button is used a search is made.
- Public – these are assets (or locations) where there is no user/custodian. The search is restricted by the Asset Site field that defaulted from the Affected Person, otherwise it is the records that the logged in user has access to.
- All – these are all assets (or locations) but is restricted by the Asset Site field or the records that the logged in user has access to. It will show the assets (or locations) which have a user/custodian record of someone other than the Affected Person.
In all three cases the select value will omit decommissioned assets or locations.
On the Location field the Public and All setting seems to be filtering by site = ‘BEDFORD’, even if the Asset Site is something different, FLEET for example. The issue has been registered with IBM Support (APAR IJ35035). It should be working the same as for the Assets field.
The attribute ASSETFILTERBY and the domain of the same name controls the setting of the Select Value on the Asset and Location fields. The domain has values of ALL, PUBLIC, USERCUST. The default value defined in Database Configuration is “!USERCUST!”, hence why as standard the radio button starts with the User/Custodian setting.
Asset and Location Defaulting Rules
On the Create Service Request application a part of the Self-Service module, the Location and Asset Site fields can be defaulted from the Affected Person. This does not apply to the Service Requests application; it is only the Asset Site, which is defaulted from the Affected Person, and not the Location which will initially be blank. The default originates from the Person’s Site field in the People application. The defaulting on the Service Request only occurs if the Asset Site field is blank.
Maximo will default the Asset from the Location if there is only one asset that belongs to the operating location.
If the Asset is entered first, then the Location field will be populated to the location where the asset belongs.
Whenever the Location or Asset is entered the Asset Site field at the bottom of the first column of fields will be populated.
If you are using Configuration Items (CIs), then the CI can have an Associated Location or an Associated Asset. The Configuration Item field can be populated from the entry of an Asset or Location, this is using a crossover domain.
- On the Location field the crossover domain TKLOCATIONCROSSCI is used.
- On the Asset field the crossover domain TKASSETCROSSCI is used.
These crossover domains can be used to copy over other attributes from the Location or Asset objects. The crossover domains are examples of crossing over a non-persistent field to a persistent field, the CINUM attribute is non-persistent on the Location and Asset objects.
If you enter a Configuration Item on the Service Request, then the cross over domain CICROSSASSETLOC will copy over the asset or location from the Configuration Item record, remember only one of those could be populated. However, you may find both the Asset and Location fields are populated.
- If the CI has an Associated Asset, then the Location on the Service Request is the location belonging to the asset.
- If the CI has an Associated Location, then the Asset on the Service Request is the only asset that exists at that location.
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 of 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. Once proven, the classification and the values used for the attributes can be used to automatically generate the short description for the service request. When this is implemented the Description field (Summary) is left empty and a service desk agent would type immediately into the long description field (Details).
In the example shown, I had already selected the classification and then launched the dialog again so that I could show how the service request classification is derived from the classifications in the selected classification hierarchy.
- 2 Request for Service
- 201 IT
- 20102 New/Upgrade Software
- 2010205 Other
The Classification is the concatenated classifications but with a backslash between:
2 \ 201 \ 20102 \ 2010205
The Classification Description looks as if it is the concatenated descriptions but with a backslash between which would be:
Request for Service \ IT \ New/Upgrade Software \ Other
But if you look closely, it is:
Request For Service \ IT \ New Upgr Sftw \ Other
This is because you can change the description for the classification hierarchy in the Classifications application. When doing so you really need to think about the key words that the user will search for. In this case, it would be Software, so shortening to Sftw will mean that it would not be found. It would have been better as:
Services \ IT \ Software \ Other
The Summary field has been generated from the classification. Classifications allow the description fields of the object where the classification is applied to be generated from the classifications in the hierarchy and their attributes. With the attributes the description prefix and unit of measure are used around each attribute value.
It is normal to use the description generation function for service requests, at least initially. For service requests at NEW status originating from either the Create Service Request application or Submit a Service Request Work Center you can more easily make use of the Select Owner and Take Ownership actions from the List tab of the application if there are consistent descriptions. Hence, when taking a service desk call while using the Service Request application I would leave the Summary field blank and add notes directly in the Details field. When you classify the Service Request anything which you entered in the Summary field will be lost when the description generation function kicks-in.
In the Details field, which is the long description of the Summary field, there is a Rich Text Formatting toolbar. I have entered the details of the request and the justification – “Ed Adams needs permission to buy Camtasia 2021 for Mac so that he can generate professional training materials.”
The Reported Priority is the priority that the requester gives, a value in range 1-4 where 1 is Urgent, 2 is High, 3 is Medium, 4 is low. This is defined in the domain called TICKETPRIORITY. Ed Adams requires this urgently (2).
The Internal Priority is usually the priority used by the Service Desk team to determine target dates when a Service Level Agreement is applied to the Service Request. It uses the same domain and set of values as the Reported Priority. For this type of request the priority is always medium (3).
There are two hidden fields Impact and Urgency which can be used to derive the Internal Priority, but you will need to create a Maximo formula to derive it based on how you set-out your matrix between the two values entered for impact and urgency.
Ticket Service Groups and Services
The two fields Service Group and Service are defined in the Service Groups application. 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, locations 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. For the Service Group IT, we have chosen the Service SUPPLYCH – Supply Chain.
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/. Service Groups and Services can also be associated with an Asset Type, Purchase Contracts and Lease/Rental Contracts.
Why do we have both a Classification and Service Group/Service? Think of the classification as describing what is being requested. Think of the Service Group/Service as being all the people, equipment and other things that provide a service to a requester – service management. From an IT perspective, services are managed by a team, so you can sometimes reverse engineer from the team’s name to derive a service name. In the example, it is the IT Procurement team that will satisfy the request, hence the Service Group of IT and Service of Supply Chain. The Procurement team may be buying goods and services for many departments, and so the service is not the team, but the service the team provides.
You use the Service Groups application for creating Service Groups and their Services. You can associate either a Contact (Person) or a Contact Group (Person Group) with both the Service Groups and Services. In this case I have added the ITPROC team to the IT-SUPPLYCH service.
The Service Group of PRODUCTN will not be able to have the same SUPPLYCH service, the list of service groups and services need to be a single unique list.
Remaining Service Request Detail Fields
Continuing with the second column of the Service Request Details section we have four more fields.
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 Organization behind the scenes, so that the selection of Site is restricted to those that belong to the same Organization. Alternatively, if the Site has already been set then this sets the Organization field behind the scenes and consequently only companies that belong to that organization can be selected.
The Site field will probably be one of the last fields set before saving the new service request. It needs to be set before you can apply a Service Level Agreement, otherwise you will receive the error “BMXAA3965E – Please select a site before applying an SLA.”. It also needs to be set before you can use the action Create Work Order, otherwise error “BMXAA4293E – Site is required to create Work Order.” will be received. The Site field is set to the user’s default insert site if you use the Start Timer action, so better to set it first, the Default Insert Site of the user in a central service desk may not be the correct site for creating a follow-up work order.
In many Maximo environments a follow-up work order will be created. On a work order the site of the location and asset must be the same as that for the work order. It is quite common then to align the Asset Site and Site fields to the same value through a small piece of customization.
The SLA Applied is a checkbox indicating when an SLA has been applied to the Service Request. If you see target dates lower down in the Service Request applications, more than likely these were generated from a Service Level Agreement being applied. I will be writing articles on Service Level Agreements and how they are applied to a Service Request.
The Create WO Options field is used in conjunction with the table window called Multiple Assets, Locations and CIs and it determines how each record in this table will be treated if you create a follow-up work order to the service request. The options are:
- MULTI – The records are created in the same table window of the work order
- NONE – Do not copy the records
- TASK – The records each become a task of the follow-up work order
- CHILD – The records each become a child work order of the follow-up work order
- TOPLEVEL – Each record becomes its own work order
We said that we would return to the Address Information section. You can see that the Service Address 1015 – Terminal 3 Heathrow Airport has been derived. The selection of asset 2172 derived the service address.
This is not because a service address has been applied directly to the asset, but it is being derived from the location of the asset, OFFICE in this case, and location OFFICE has the Service Address 1015. The Service Address tab on the Assets application will either show a service address in the Address Information section or if it is being derived, then the Location Hierarchy section will provide the location from where it was derived. This is using the location hierarchy that is marked as the Address System.
You can either add a Service Address directly to an asset or a location, or a service address can be derived by looking up the asset and location hierarchies until it finds a service address. The service address and its address fields are then copied to the service request to the object/table called TKSERVICEADDRESS where the fields can be modified, if required.
You do not need to use a Service Address; you can just type into the address fields in the Service Address tab of the Service Request. If there is a Service Address and any of the fields are modified, including the Directions or Reference Point fields, then the service address field will be blanked.
Note. The Service Address Description field should be something meaningful to allow it to be found from a list of service addresses and to be useful to someone trying to find the address. In the UK it would include the house name or number, street, town/city and postcode. In other countries, it might be a different set of fields. There is no generation of the service address description from other fields, which would be useful, and would encourage users to enter the data in the right fields.
Note. The Formatted Address is derived from the address of the map position for the service address and so shouldn’t be used as the description for the service address or as an address field. The Street Address field would be the first line of the address. If the country where you operate has structured street addresses, then a dialog can open to help you enter the street address in a structured way.
There are three existing Maximo Secrets articles on Service Addresses, one about the application http://maximosecrets.com/2015/04/12/service-address/ , the Service Address Options in the Organizations application http://maximosecrets.com/2015/04/12/service-address-options/ , and Inheriting Service Addresses http://maximosecrets.com/2015/04/12/inheriting-service-addresses/ .