The Self-Service applications have a license profile for which there is no license fee, allowing them to be used by a wide number of users. There are two applications associated with Service Requests and this article will look at both. The Submit a Service Request Work Center will be the subject of another article.
We will be logging in as the user REDDING – Tony Redding.
Create Service Requests application
When you use the Create Service Requests application a record is automatically created, and several fields will have been entered for you. In many cases the user will just add the details of what is needed and then they use the Submit button at the bottom of the screen. This article will go much deeper than this simple scenario, for example it will explain how fields are defaulted.
When the Create Service Request application is launched some fields will be filled automatically.
- Reported By – is filled with the person of the logged-in user, REDDING in this case
- Phone – is the primary phone of the person record for the logged-in user
- E-mail – is the primary e-mail of the person record for the logged-in user
- Affected User – defaults to the Reported By person, but it may be changed
- Reported Date – defaults to date and time now
These defaults will be typical for a new Service Request.
The user’s Profile and in particular the Personal Information menu option shows where the Primary Phone or Primary E-mail are set and where they can be changed. The Person’s Site and Location are also defaulted on to the Service Request, hence why OFF401 – Office #401 was used for the Location field.
You may find that the Person’s Location set on a user’s personal information does not default to the Location field, this is likely to be because the field “Default Location to Service Request?”, found at the top of the Workflow and Work Order section in the People application, is unchecked.
The Reported By person will be defaulted to the logged in user, as is the Affected User but both can be changed and this will accept either a value found from the Select Value, i.e., a person who is already registered in Maximo, or someone who is not. In this case, I typed Andrew Jeffery and in the Select Value dialog that opened, I chose the Continue button.
Note. A user who is going to change the Reported By or Affected User fields should first use the Select Value and search in the Name field to see if there is a person record already defined. If no record is found, then it is quicker to cut and paste from the Name to the Person field before using the Continue button. If the Person field in the Select Value is empty, then the Continue button just closes the dialog.
As you can see after pressing continue the Reported By is changed, but you would need to manually change the phone and email address as I have done. The Affected User is not modified.
This illustration would be a little unusual, it is much more likely that you retain the defaulted Reported By, Phone and E-mail and just change the Affected User. I will change the Reported By back to REDDING to continue with the scenario.
The location field has a Select Value which defaults to a search by User/Custodian, the other two options are Public and All. The User/Custodian search is using the Affected User and not the Reported By person. I will choose CONF400 which is where the issue exists and then press the Continue button.
After changing the Location to CONF400 – Conference Room #400, Asset 1005 – Fire Extinguisher, has been defaulted onto the service request. If there is only one asset that belongs to an operating location, then it will be defaulted when the location is entered. This is how Maximo works, and in most cases, this is what you would want, however, there is no property or switch to disable this. The workaround to stop this default from occurring is to use a crossover domain (to copy a null value into the ASSETNUM field), automation script, or Java customization depending on your implementation preference.
If we navigate to the Locations application for location CONF400 and use the Associate Users and Custodian action we can see that REDDING is defined as a User, they are also set as Primary because they are the only person associated with the location, and Maximo will require one of the users or custodians to be set as primary.
It is preferable for the reporting person to be able to select the location or asset easily and by default Maximo uses the User/Custodian feature to limit the locations and assets. The Select Value on these two fields uses the Affected User and not the Reported By field. The other two settings are:
- Public – Which will show all the locations and assets which have no user or custodian
- All – Which will show all the locations and assets, irrespective of whether they have a user/custodian or not.
For those Maximo organizations who are using multiple sites, the Select Value for the location and asset field will be filtering to the Reported By Person’s Site, in this case REDDING has this set to BEDFORD in their profile. The location and asset Select Values will be restricted to this site, and if you are allowed to navigate to the Locations or Assets application and try to Return With Value for a location or asset from another site, you will receive the error message “BMXAA0090E – Asset T2002 is not a valid asset, or its status is not an operating status.” or something like.
Incidentally, the setting of USERCUST, PUBLIC or ALL is defined as the default value for attribute ASSETFILTERBY in the SR object, the default value found in Database Configuration is !USERCUST!
In our scenario the Fire Extinguisher (asset 1005) is not the correct asset, the conference room is too hot (there is no fire!). If we blank the asset field, then if Service Addresses are being determined then you will be warned “BMXAT0331W – You are deleting the asset of this SR, which changes the service address on the SR to match the service address of the current location. Click Yes to accept the service address of the location. Click No to clear the service address data.”
Service Addresses are not used on all Maximo implementations, but if they are being used then the Service Address on the Service Request can be derived from either the location or asset. It may be derived from the location which is higher in the address system than the current location. You can determine from where the service address is being derived by navigating to the Assets or Locations application and the Service Address tab. At the bottom of the screen in the Location Hierarchy section. you may find from which location it is being derived. In the case of location CONF400 the Service Address is being derived from the OFFICE location which has an Ancestor’s Address of 1015 – Terminal 3 Heathrow Airport.
I used the “Yes” button in the warning message, it would be normal to accept the location’s service address, rather than clearing it altogether.
The Reported Priority has a Numeric domain (TICKETPRIORITY) of 1 to 4 where 1 is Urgent and 4 is Low Priority.
The Reported Date field below the Reported Priority is defaulted to time now when the Create Service Request application is launched, it is not modified when the record is saved. If a user is part way through raising a request and receives a telephone call, there will be a time delay before they reach filling out the request and using the Submit button. If a Service Level Agreement is going to be applied, then it uses the Reported Date in order to calculate the target dates for the SLA commitments.
The STATUSDATE and AFFECTEDDATE are both set to the date/time when the service request record was saved to the database.
In the Request Description section there is both a Summary (short description), and a long description, which accepts Rich Text Formatting (RTF). I’ve used the RTF to illustrate “The conference room is too hot to be used, please can you review ASAP.” Notice that the description “End User Issues,Facility,Heating/Air,Too Hot” seems to have been generated, it has, it has been generated from the selection of the Classification 1 \ 103 \ 10301 \ 1030101 – End User Issue \ Facility \ Heating/Air \ Too Hot.
If you navigate to the Classifications application from the Classification field, you will see that Generate Description and Use Classification are both checked.
- Generate Description – determines whether the description generation function is switched on for the classification.
- Use Classification – determines whether the classification’s description “Too Hot” is used in the description generation.
You would find that Use Classification is set for each level up the classification hierarchy:
- End User Issues
The description generation is taking the classification description from each level where Use Classification is checked (starting at the top of the hierarchy) and concatenating the descriptions together with a comma separator, hence the resulting “End User Issues,Facility,Heating/Air,Too Hot”.
For this classification I had entered two new attributes:
- CURTEMPC – What is the current thermostat temperature?
- THERMWORK – Is thermostat working OK?
The description generation can also use the attribute values. The Description Prefix field is used before the attribute value and the Unit of Measure is used after the attribute value.
On the far right-hand side of the Attributes table window is a button called “Use With Object Detail”. For each object where the classification can be used there is a record for each attribute. In this record the “Use In Description Generation?” attribute allows the attribute value to be used in the generated description for the object, in this case SR (Service Request). Towards the end of the article, after we submit the Service Request, we’ll show you an example of a description which includes attribute values.
Notice that the Mandatory attribute is checked.
The two attributes were copied to the new service request and if you tried to use the Submit button at this point you would receive the error message “BMXAA0191E – Field Numeric Value for attribute CURTEMPC is required. Please enter a value.”.
The value of 27 was entered in the Numeric Value field for the attribute CURTEMPC and for the THERMWORK attribute there is a Select Value with, in this case, a choice of Y – Yes or N – No. The attribute value is not entered in the same column, because it depends on how the attribute was defined, in nearly all cases values will need to be entered in either the Alphanumeric Value or Numeric Value columns, it is obvious which one to enter the value in.
While you are creating the service request you can also use the buttons to Attach Files or Attach Web Page.
With the Attach Files a dialog appears, and you use the Select Files button to select a file, in this case a screenshot of the error message from before. You will need to enter at least a description for the file – Screenshot of Error Message.
After you use the OK button, a document will be added to the document library and linked to the service request, the document identifier has used the autokey, in this case 1025.
We are now ready to use the Submit button.
You will receive a message “Service Request 1273 has been submitted. Record your Service Request for future reference.” with three buttons:
- View Details
- Return to Start Center
- Create Another Service Request
We will use the View Details button; the other two buttons are self-explanatory.
View Service Requests application
You can see that service request 1273 has been created with the information we provided, it is at NEW status. Notice that the service request description has been appended with the attribute values 27.0 Deg C, Y. The Deg C is the unit of measure for the CURTEMPC attribute. The Y at the end is coming from the THERMWORK attribute. Either you do not need to include this attribute in the description generation, or a description prefix could be considered, for example, Therm. Work?
Note. That the CLASSSPEC attribute ATTRDESCPREFIX. – Attribute Description Prefix is only defined as ALN 8, and to fit “Therm. Work?” you would need to increase this to at least ALN 12. You also need to consider the length of the Service Request Description attribute, as, with a lot of prefixes, values or units of measure, the description may soon reach the point where it starts to be truncated, which for service requests (SR object) is after 100 characters.
Notice at the top of the screen you can view Previous Record and Next Record or perform a Search, we’ll see an example of the Search screen later in this article.
At the bottom of the View Service Requests application you can see the attachment that was added earlier, and you can attach additional files or web pages.
In the Log tab you can communicate with the service desk agent, and view records that originated from a follow-up work order.
When you use the Update Service Request button a dialog opens allowing you to enter a Summary and Details, which again has the Rich Text Formatting button ribbon. I entered:
- Summary – Room still too hot, 28C today
- Details – I reported this issue yesterday, I didn’t see anyone during the day, have you been out to see for yourself how hot the room is. As of a few minutes ago it was 28C, please respond ASAP.
After pressing OK, the Log Note has been added to the service request. You will be able to see what was written in the details if you click any field in the table row.
If you use the Search button, or if you launch the View Service Request application from the application menu you come to the same page shown. There are a few fields you can search by, mainly the fields found in the header section when creating the service request.
The service requests which you can view are those which you created yourself (Reported By) or those which were created on your behalf (Affected User).
You may have noticed the button Linear Asset Search. Both the Create Service Request and View Service Request applications support the referencing of issues associated with linear assets, this will be the subject of another article.
Configuration Item Defaulting on Service Request
You might have noticed that earlier I skipped over the Configuration Item (CI) field, so a few words about how using a CI effects the defaulting of an asset or location.
In the Configuration Items application, a CI is defined as anything on which you wish to manage change control, and this is normally something with a version number. It is used a lot in the IT world as part of configuration management, but it would also be used in highly regulated environments where there is a configuration audit. If you hear the term Change and Configuration Management, think CIs.
In the example shown, I have created a CI to represent the software version of my Apple MacBook Pro. This has a classification with two attributes in the Specifications table, to record the operating system name (macOS Big Sur) and the operating system version (11.6). A CI can be associated with an asset, location, or item, but they can only reference one CI. The CI Owner defaults to the one marked as the Custodian of the asset or location as found in the action Associate Users and Custodians in the Assets and Locations application. In an EAM world a CI might be used for a software component or a document.
If the location, which defaults from the Reported By person, has an associated CI you will find the Configuration Item field has been defaulted. This is using a crossover domain called TKLOCATIONCROSSCI which will be found in the Domains application. The crossover domain fires on the location field on the service request and copies over the CINUM on the LOCATION record, this is an example of using a crossover domain to copy data from a non-persistent field to a persistent field. The crossover domain can be extended to copy over other location fields to the service request.
I have entered asset 2171 onto the service request and if a location exists you may receive the warning message “BMXAA5327W – The asset you have entered does not reside in the current location. Would you like to update the location with this new asset’s location – OFFICE? Clicking Close will return you with no changes to the asset or location.”. I have used the Yes button.
Asset 2171 has now been added to the service request, along with its location OFFICE and the CI for asset 2171, Configuration Item 1001, which you saw in the introduction to this section. This is using a crossover domain called TKASSETCROSSCI which will be found in the Domains application. The crossover domain fires on the asset field on the service request and copies over the CINUM on the ASSET record, another non-persistent field. The crossover domain can be extended to copy over other asset fields to the service request.
Incidentally, if there is no defaulting of the location and you went to the Configuration Item field and selected CI 1001 then you would end with Asset 2171 and Location OFFICE being populated. This is using a crossover domain called CICROSSASSETLOC which will be found in the Domains application. The crossover domain fires on the configuration item field (CINUM) on the service request and copies over the ASSETNUM and LOCATION attributes.
The location field on Configuration Item 1001 was blank, the crossover only copied across asset 2171. However, asset 2171 resides in the OFFICE location, hence why the location field was also populated, it was triggered from the asset field.