An overview of Alerts in MAS 9.2

Prior to MAS 9.2 Maximo had no built-in alert functionality that would help to support proactive maintenance and thereby improve asset availability. An alert is anything which needs to be brought to the attention of operations or maintenance so that it can be consistently dealt with. Examples:

• An observation made while performing a daily round that should be investigated.
• A reading or measurement that has not yet exceeded any limit but is abnormal and should be reviewed.
• An alarm produced by a sensor, SCADA or other external system which needs immediate attention, or which needs attention if it becomes repetitive within a specific period.

Prior to MAS 9.2 there was some functionality to support an alert. A service request could be raised by a technician or operator from a mobile device. An observation could be made on an inspection or work order and a follow-up service request created to investigate this. Measurements or observations linked to a Condition Monitoring point could generate a work order when a corrective action is required. Maximo Monitor could be connected to sensors, historians, SCADA, building management systems or other external systems to raise a service request when an alarm is triggered or a threshold is reached. What was missing prior to MAS 9.2 was a consistent way of capturing alerts, routing them to the right team or person and then handling each event through to closure.

In MAS 9.2 this has been addressed by:

• Creating a new type of ticket called an Alert. The Alerts application is new classic UI application, it is very similar to the original Incidents application that you would have access to if you had Health, Safety and Environment (HSE) installed.
• A new Tickets application built using the Maximo Application Framework to provide a more modern user interface (UI).
• Enhancements to the Condition Monitoring application to automatically raise an alert when a measurement or observations exceeds the warning limits of the condition monitoring point. There is also functionality on the Assets and Locations applications to inhibit alert generation.
• Enhancements to Maximo Monitor to create an alert when an alarm is triggered.
• Using AI to review the alert and provide insights and recommendations from which you may create a work order to investigate the alert or take action to resolve the underlying cause. The recommendations might suggest an inspection or calibration, component checks (valves, sensors, impellers), a configuration review, or to make monitoring improvements.
• Alerts are visible within the Asset Management tab of the Operational Dashboard and in the Alerts and Meters tab of the Assets & Locations application, alerts are applicable to both assets and locationsA physical place where assets exist and where work can be performed. More.

Stefan Hoffmans wrote an informative article – IBM MAS 9.2 Alerts: The Missing Layer Between OT and IT which provides some additional context. Check it out here. https://community.ibm.com/community/user/blogs/stefan-hoffmanns/2026/07/03/ibm-mas-92-alerts-the-missing-layer-between-ot-it

In this article we’ll start with the first bullet and review the new Alerts application.

Alerts – An Overview of Tickets functionality

The Alerts application is using the classic user interface (UI) and anyone who knows the background of service requests, incidents and problems and how Maximo originally implemented ITIL v3 in April 2005 will look across the tabs and see a resemblance with the Incidents and Problems applications which also has tabs for Activities, Solution Details and Failure Reporting.

Service Requests, Incidents and Problems are three classes of Tickets, and these applications were designed so that the functionality was commonly built into a Ticket and then used by those applications as necessary. Service Requests does not have Activities, Solution Details and Failure Reporting tabs, but Incidents and Problems do, and the application difference between Incidents and Problems is very slight. They represent three different processes in ITIL, hence why we had three applications.

The original Incidents and Problems applications are available if you install Health, Safety and Environment (HSE), but HSE clones these and enhances the clone for other ticket classes, a Defect is an extension to an Incident, and an Investigation is an extension to a Problem.

An Alert is another database view onto the TICKET table where, in this case, the CLASS is a synonym of the domain called TKCLASS with an internal value of ALERT, the fourth view after SR, INCIDENT and PROBLEM. The ALERT object is at the System level, this is common to all Ticket based objects, you will find that some functionality will only work after you have added a SiteA structural element of a Maximo database that is used for data separation. More, for example applying an SLA, the Site field will be found further down on the main tab on the right-hand side.

The good news is that I have previously comprehensively written about the Tickets functionality in Maximo, 22 articles which you can find all in one place here – https://maximosecrets.com/deep-dives/tickets/. I’ve even recorded a 15-episode podcast series on Service Management which is also relevant – https://maximosecrets.com/service-management/

If you know Service Requests, but not Incidents and Problems, then there is an article which just covers those subjects – https://maximosecrets.com/2021/11/19/incidents-and-problems/, it will tell you about the three additional tabs not found on a Service Request.

I’ve decided to provide an overview of general tickets functionality, what you will find with Service Requests and then a few bullets describing the differences found with the Incidents, Problems and now the Alerts applications.

Overview of Tickets Functionality

• There are now four types of ticket, Service Request, Incident, Problem and Alert. Each is a database view onto the TICKET table. The Service Requests (SR) application is often used as the base application of a Service Desk.
• Multiple people can call a service desk about the same issue or observation. If you have access to the Incidents and Problems applications, then an Incident will be raised to track the issue through to resolution and the return of service. Therefore, multiple SRs can be linked to the same Incident. The SR is used to track the communication with each requester, the foundation of Service Management, the Incident is used to track the progress of the issue.
• A Problem is raised from an Incident to investigate the root cause of one or more underlying incidents. The problem can be marked as a Known Error. When the underlying cause is permanently fixed the problem is resolved.
• An Incident and Problem can have multiple Activities to track the progress between multiple teams or people.
• A Solution can be considered a knowledge base document that can be applied to Incidents, Problems and now Alerts, it might be a workaround or a final solution. It consists of three long description fields Symptom, Cause and Resolution.
• Each class of ticket has its own set of statuses, but the internal values are the same, New, Queued, In Progress, Pending, Resolved and Closed. Service Requests has two synonyms of Closed, Rejected and Cancelled. Incidents have a synonym of Queued, Waiting on Review. The Alerts application is a little different, but we will get to that later.
• The status of one record can be inherited from another, for example when an incident is resolved it can resolve the service requests linked to it. If a follow-up work order is created from an incident, then when the work order is completed, it can resolve the incident. If the incident has activities, then the resolution of the incident can complete any outstanding activities.
• Tickets exist at the System level. There is a Site field (SITEID) which typically is populated early in the processing of a Service Request but there is no standard functionality to populate this because Maximo is designed to provide a centralized service desk, on many Maximo implementations it will be defaulted through configuration.
• All classes of ticket can reference a single asset, location or configuration item (CI). A CI is something which is under configuration control, a document, software, etc. If the ticket effects multiple assets, locations and CIs then these can also be entered in the Multiple Assets, Locations and CIs table. When creating work orders from the ticket you can decide how the multiple assets, locations and CIs should be processed, for example one work order for each, one task for each, one child work order for each, ignored completely, or copied to the same Multi table on the work order.
• Tickets and Work Orders of each class can be related to each other in different ways, the most common is when one record creates another record, the relationship types are originator and follow-up. Crossover Domains are used when one record creates another to define what attributes are copied and the conditions which may be set to allow the attribute to be copied. There are other relationship types including when a global issue is declared and other records are linked to this global issue. A global issue is declared when multiple persons report the same issue. Any ticket can be related to another ticket or work order and vice versa.
• There is a Ticket Template application that is used to create common requests and issues in a consistent manner, it defaults data onto the ticket record. A Ticket Template can be applied when creating a Service Request from the Start Center Quick Insert portlet, or from the Operational Dashboard Quick Insert card. It can be applied by the service desk agent or control room after the ticket has been created.
• Classifications are used to describe the type of services and incidents likely to be received by the service desk. The Classification may have attributes which in many cases will be questions that are used to capture relevant additional information. The classification hierarchy may be several levels deep, often 4, 5 or more. It is used to help to find other similar tickets.
• Each ticket record has a Service Group and Service field; they are defined in a two-level hierarchy in the Service Groups application. The two fields are used in Service Management reporting, and they can be associated with Assets, Locations and Configuration Items. They can also be used to relate ticket and work order records.
• All classes of tickets and work orders can be owned by a Person or Person Group (team), this is called ticket and work order ownership. Ownership is tracked in an ownership history table which can be viewed in the View History dialog.
• There is a Work View application (Administration module) where queries can be defined and used on a Start Center or Operational Dashboard to display all the records which a user owns or is owned by the teams for which they are a member (Person Group).
• It is possible to track the time spent on a ticket or activity by each person who has a labor record. The ticket-based applications have actions Start Timer and Stop Timer which will create and complete a Labor Transaction record in the background.
• Tickets and work orders have a Work Log and Communication Log. The log notes created against one type of record can be viewed on other records, for example a log note on an incident is visible on the service request which created the incident, a log note on a work order can also be viewed from the ticket that created it. The visibility of these log notes also works with records which are related to records that are marked as the global issue. The Communication Log represents emails that have been sent out from a record.
• A Service Level Agreement (SLA) can be applied to each class of ticket, the commitments will create one of three target dates on the ticket, based on the contact, response or resolution that you defined. There are three stages you should perform, the creation of the SLA, configuring it so that the right SLA is applied to the ticket, and then monitoring the tickets against the SLA and reacting to any breaches that occur through an associated escalation.
• Service Requests can be created through self-service or mobile applications, and those users can view updates made to the service request or on follow-up records.

I’ll be using the overview provided above to test out this functionality from the Alerts application, but I will only be providing the results of those tests rather than creating a document with perhaps 100 screenshots. First, I’ll describe the extra tabs that you don’t find on the Service Requests application, and I’ll explore any differences that we find in the Alerts application that you do not find in the other ticket-based applications.

Alerts – Tabs that do not exist in Service Requests

There are three tabs that do not exist in the Service Requests application, they do exist in the Incidents and Problems applications and their HSE clones, but many of you will be unfamiliar with these.

Activities

A ticket allows multiple Activities to be created to track its progress. Activities is not provided out-of-the box on Service Requests but it can be very easily configured, even more so now that the Alerts application has been provided, a matter of cutting the XML from the Alerts application and pasting into the Service Requests application, which you do in Application Designer.

An Activity is a class of work order; it has the same statuses, and a lot of the same functionality as a work order. The Activities and Tasks application is provided for teams and individuals to progress each activity created. In the screenshot I have just used the New Row button and as you can see data has been copied from the Alert to the Activity, the description, its long description, the location and asset and other fields that are defined in the Crossover Domain TICKET2WO.

Each table window row has buttons on the right-hand side to Select Owner (a person or person group) and to Change Activity Status. If I select WILSON as the owner (I am logged in as WILSON), then the activity will appear in the Technician mobile application using the query My Work Order and can be processed like any other work order.

Activities can also be viewed and processed from the Work Order Tracking application, but you need to change the default query to allow records with a class of ACTIVITY to also be displayed. The Go To on the Activity field will take you through to the Activities and Tasks application where you can plan and record actuals, including materials, tools and services, and enter a failure report. Log Notes entered on the activity are not visible on the parent ticket, but this could be configured.

A Ticket Template can be set up with a set of activities, so these activities could be created automatically when a Ticket Template with a Class of ALERT is applied. If the Activity on the Ticket Template references a Job Plan, then the Job Plan is applied when the Ticket Template is applied and the activity created. This provides a powerful way of handling a type of alert in a consistent manner, whether one activity with a set of tasks is created, or a set of activities created, or indeed a combination of the two.

One difference you will find with the Service Requests application is that the Time Tracking table is moved from the main tab to the bottom of the Activities tab.

Solution Details

The Solution Details tab has three long description text boxes for Symptom, Cause and Resolution. You do not need to apply an existing Solution but if you do then those three fields are copied from the solution record, but you can then modify the text. There is also an action Create Solution to create a solution record from the text that you enter on the alert. Each of the fields Symptom, Cause and Resolution has a rich text formatting toolbar. To apply an existing solution, it needs to be at Active state.

Solutions are typically associated with the same classification as the ticket to which it is applied, and this narrows the search. The Solution field has a Classification Search. There is also an action Search Solutions that can assist in looking for a solution to apply.

Only one solution can be applied to a ticket at any one time, but a different solution could then be applied. There is no history of the solutions that have been applied, but this could be added through customization. Solutions are only applied to Tickets, and it would not be possible to get around this by applying a solution to an activity, solutions are currently not applied to work order records in Maximo.

Failure Reporting

The Failure Reporting tab is likely to look familiar as it works in the same way as a failure report on a work order. The Failure ClassA Failure Class is the top-level Failure Code of a Failure Hierarchy. More, PUMPS in this case, is derived from the asset’s failure class or location’s failure class with the one on the asset taking priority. The blue List Failure CodesFailure Codes exist as part of a Failure Hierarchy and are a Failure Class, a Problem, Cause or Remedy Code. More button is then used to select a Problem, Cause and Remedy and together they make up the failure report.

An Activity can also have a Failure Report and so it would be possible to provide multiple failure reports, for example if you wished to record the failure against the pump and you wanted to report a failure against a component of the pump.

Alerts – Differences with other Ticket Applications

When you look through the Alerts application you won’t find many differences with Service Requests apart from the three tabs, Activities, Solution Details and Failure Reporting which we discussed in the previous section of this article.

The statuses found in the Alerts application are taken from the synonym domain ALERTSTATUS and are NEW, ASSIGNED, INPROG, SUSPEND, RESOLVED and CLOSED. The ASSIGNED status is a synonym of QUEUED.

For Service Requests and other types of ticket, when a record has an assigned owner or owner group then the status is automatically changed from NEW to QUEUED, for alerts this automation works but it is to ASSIGNED status rather than QUEUED. You cannot return to NEW status from ASSIGNED or any other status.

There is no PENDING, REJECTED or CANCELLED statuses that you get with a Service Request, all alerts should be processed from NEW through to CLOSED. There is an action Edit History Alert for modifying the record once it has reached CLOSED state. In the other Ticket based applications there is a Common Action and Signature Option for changing status to PENDING but one has not been provided for SUSPEND in the Alerts application, it would be reasonable and consistent to have one. I’ve raised an IBM Idea for this – https://ideas.ibm.com/ideas/MASM-I-2001

Suspended (SUSPEND) is not a status found on any other ticket-based application. If an alert is being created from a Condition Monitoring Point, then what you don’t want is multiple alerts being created in a short space of time between the point when the first alert is created and before anyone has had a chance to review it. If you change the status to SUSPEND then if you used the action Generate Alert on the Condition Monitoring record you would obtain the errors:

BMXAA10338E – An error occurred while generating an alert for measure point 1001.
BMXAA10340E – Alert generation is suspended for this measure point.

If the status of an alert for the same asset/location and meter is at another status, other than SUSPEND, then a new alert record will be created. I am aiming to write another article on the changes to Condition Monitoring application made in MAS 9.2 that will show an example of this. This SUSPEND functionality works with both Gauge and Characteristic meters where there is a corresponding Condition Monitoring Point. There is also other functionality around inhibiting alert generation on both the Assets and Locations applications.

Once the alert reaches RESOLVED status you will find that any associated activities will be set to COMP status. At RESOLVED state you cannot change status to SUSPEND, but you can change back to ASSIGNED or INPROG. Once the alert is CLOSED then the associated activities’ status will be marked as CLOSE.

The only field difference between the Alerts application and the Service Requests application is the addition of the Measure PointA Measure Point is a record given to an asset or location and a meter of type gauge or characteristic. More field positioned below Asset, Location and Configuration Item. This is filled out if the alert is created from the Condition Monitoring record, the Go To menu will take you back to this record.

Testing of Alerts Functionality

I ran through a series of tests on the Alerts application using my knowledge of how other Ticket based applications work. The following paragraphs are the results.

In a MAXDEMO database there are no Classifications set up for Use With Object of ALERT, and so you will not be able to classify an alert until you do have at least one. I added ALERT to the classification PIPE_LEAK which had 10 attributes. These were copied to the Specification when I classified my alert.

In a MAXDEMO database there are no Ticket Templates for a Class of ALERT. I created one with two activities and made it active. At first, I could not apply the Ticket Template using the application action Apply Alert Template, I received the message BMXAA6565I – Create or activate SR template in Ticket Templates application, which is not an accurate message for alerts. I then realised I had added an OrganizationA structural element of a Maximo database which is used for data sharing. More to the Ticket Template, and Alerts (like other tickets) are defined at the System level until you enter a Site. After adding BEDFORD to the Site field, then the dialog to Apply Alert Template was displayed showing the active Ticket Template of class ALERT. I raised an IBM Support case about the inaccurate message.

The fields from the Ticket Template were copied and the two activities created. It is possible for the Ticket Template Activity to reference a Job Plan, I didn’t try this, but I have done so on a previous Tickets article, so I expect it will work for Alerts. Incidentally, you can use the Quick Insert portlet on the Start Center to create an Alert and apply the Ticket Template, this worked.

The Create Service Request and Create Work Order actions created the records that you would expect, and these were visible in the Related Records tab. I related the alert to a Global Incident, and this created a Related Tickets record with relationship type ISGLOBAL. I declared one alert as a Global Issue and used the action Show Similar Tickets and the button Relate Records to Global Issue and this created the records in the Related Tickets table with relationship type of RELATEDTOGLOBAL, all as expected. The Show Similar Tickets action and dialog uses the Classification as a matching criteria and only shows open tickets, it is defined using the relationship SIMILARTICKETS against the TICKET object, it doesn’t just show other alerts, but also Service Requests, Incidents and any other class of ticket.

Log Notes added to the Global Incident were visible on the alert that referenced the Global Issue. You could also add log notes to the alert. Both functions of the Modify/Delete Work Log action worked as expected. These tests were made on a suspended alert, just to make sure that this new status for tickets had no effect.

I created a Service Level Agreement against the Applies To Object of ALERT adding three commitments for Contact, Response and Resolution. After making the SLA active the Apply SLA action on the Alert application found this SLA. The View SLAs action showed the SLA and both functions of the Select/Deselect SLAs action worked as expected, the SLA could be deleted and then reselected using the dialog. When an SLA is applied the three commitments calculate the Target Contact, Target Start and Target Finish dates. The test was made with the standard Service Level Agreements application and not the one from the Service Provider add on.

There is status inheritance on tickets, this is controlled by the hidden attribute INHERITSTATUS which for alerts is set to 1. With the alert at INPROG state and with a follow-up work order with the relationship type of FOLLOWUP, when the work order is completed then the inherit status function will change the alert status to RESOLVED and when the work order is set to CLOSE the status on the originating alert is set to CLOSED. There is a System Property mxe.app.workorder.DoNotChangeTicketToINPROG which is set to 0 on my system. I did a test with an alert at status of ASSIGNED and with a follow-up work order. When the work order status was changed from APPR to INPRG then the alert status was changed from ASSIGNED to INPROG. You can turn this off by setting the System Property to 1. I didn’t test all the inherit status functions, but I have no reason to think they would not work the same as previous tests I did for Service Requests which you can read about in this article – https://maximosecrets.com/2021/11/16/status-inheritance-on-tickets/

If the alert references a linear asset, you can try I-95N if you are using the MAXDEMO database, then the Feature and Feature Label fields will be displayed as well as the fields in the Linear Segment Details section.

When you have an Incident or Problem and you use the Duplicate action you receive a dialog asking whether you wish to Duplicate Incident or Duplicate Incident and Activities, for example. The Incident needs an activity record for this dialog to be displayed. Alerts works in the same manner, except it says Duplicate Alert or Duplicate Alert and Activities.

When an alert is created, it is also written to the WORKVIEW table, when it is updated, the fields are also updated on the Work View record. I verified this using the Work View application in the Administration module.

I created a Work Queue using the Object Structure MXAPIALERT which exists, it has no Query Definitions, so I created and saved a query in the Alerts application that would find open alerts. You can create a work queue and add this to an Operational Dashboard, but I discovered there are no standard actions for alerts, there are several for service requests. I have created an IBM Idea for this – https://ideas.ibm.com/ideas/MASM-I-2002. Note, there are also no standard Communication Templates or Roles, but these could be configured.

In conclusion the Alerts application seems to be working in a similar manner to other Ticket based applications, I thought this would be the case because much of that functionality is based on the parent TICKET object and so is inherited for Alerts. A couple of little IBM Ideas (Requests for Enhancement) will help tidy things up.