Last Updated on October 29, 2023 by maximosecrets

When I started this article, I had wondered whether to make the title Corrective Action and Preventive Action (CAPA) instead. The two applications are called Incidents and Problems, and so I decided to stick with that.

I have also used this article to discuss the Duplicate and Delete actions.

Incidents – Corrective Actions, Problems – Preventive Actions

The ITIL (IT Information Library) definition of an Incident is any event which disrupts, or which could disrupt a service or reduces the quality of that service. Incident Management are the processes involving recording of the incident, its investigation and actions taken to restore the service. 

The ITIL definition of a Problem is the unknown cause of one or more incidents. Problem Management are the processes involving the diagnosis of the root cause of incidents and to determine a resolution that either eliminates recurring incidents or minimizes the impact of incidents that cannot be prevented. A Problem becomes a Known Error when the root cause is known, there may then be a temporary workaround or permanent alternative solution to follow to reduce the impact of incidents.

Problem Management has two main processes:

• Reactive – generally executed as part of service operations and directly resulting from an incident. It solves the problem associated with the incident and restores the service to the user.
• Proactive – initiated as part of service operations but driven as part of continual service improvement. It identifies the root cause and implements solutions to prevent or reduce the impact of incidents and may initiate a change to do so.

CAPA is a system for responding to issues in an effective and efficient manner, time may be of the essence in a manufacturing environment, and these are generally quality issues. CAPA will be at the heart of quality management allowing all issues and events to be recorded, to determine root cause and then propose corrective or preventive actions. A corrective action eliminates the cause of a defect or non-conformance, a preventive action tries to avoid the defect or non-conformance from reoccurring.

Corrective Actions can be handled using the Incidents application. Preventive Actions would use the Problems application in Maximo. Both applications used to be sold as a separate product, but are now part of Maximo for Service Providers, Maximo Health, Safety and Environment Manager (HSE) or are found if you are using IBM Control Desk (ICD).

Differences between the Ticket applications

There are three Ticket based applications and there is little difference between Service Requests, Incidents and Problems. The design of these application that were part of Maximo v6 deliberately made a set of core functionality with different applications so that clients could separate the data and configure them independently of each other, particularly when implementing Workflow processes. 

Each application shares the same underlying table TICKET. The three applications are based on three views, SR, INCIDENT, PROBLEM which differ according to the value of the class (TKCLASS) of the ticket. Therefore, everything I have written about in previous articles on Service Requests will be the same for Incidents and Problems.

The differences between the three applications can be summarised as follows:

• Each application has a separate status Synonym Domain (SRSTATUS, INCIDENTSTATUS, PROBLEMSTATUS)
• Incidents and Problems have an Activities tab
• Incidents and Problems have a Solution Details tab
• Incidents and Problems have a Failure Reporting tab
• A Problem can be declared as a Known Error and has a Known Error Date

As each application is based on the same functionality it would be possible to clone Service Requests to create an Incident and Problem application. You may be breaking licensing rules, but I don’t think so. Activities, Solutions and Failure Reporting all exist as part of Maximo, but Incidents and Problems make these features easier to use. I really do not understand why these applications are not part of core Maximo. Each of the products, SP, HSE, ICD have extended these applications, so they probably go completely unused by most clients, a pity because the features are useful.

Most of the remaining part of this article will focus on the Incidents application and we will only look at the Problems application for the Known Error.

Activities Tab

On the Incidents application the Activities tab has two table windows the top one for Activities and below it Time Tracking, which on a Service Request is at the bottom of the main tab.

An Incident can have multiple Activities. An Activity is a class of a work order (WOACTIVITY) and when you look at the fields, they are the same as you would see on the Work Order Tracking application. A Ticket Template when applied to an Incident may have multiple activities and so the Activities table may be prepopulated.

The default status is WAPPR, the same as it is on a work order or task. The first two buttons at the right-hand end of the Activities table window are Select Owner and Change Activity Status.

There is a hidden YORN field HASACTIVITY which is populated when an Incident has activities.

From the Activities field you can navigate to the Activities and Tasks application, but how do you tell the difference between an Activity and a Task?

• When it is an activity, you have tabs for Plans and Actuals. The top left class field says ACTIVITY and the activity number is shown adjacent and to the right – T1259 in this case. The task number is blank. 
• When it is a task, there is a tab called Resources with two subtabs for Plans and Actuals. The top left class field is more likely to say WORKORDER, but it could say CHANGE, RELEASE or ACTIVITY. The parent work order field is shown adjacent and to the right. The task number will be populated.

Many believe activities and tasks are the same thing, not true, they are different types of records that share the same application Activities and Tasks. For an Activity the Plans and Actuals tab has a Tasks table window, which is not shown on the Resources tab, the record is already a task. You can apply a Job Plan to an Activity and not to a task. It is closer to consider an Activity as a type of work order rather than a task.

What I find confusing about the Activities and Tasks application is that when it is a task you do not get to see the description of the parent record, which is easily remedied with a bit of configuration. 

Also, when it is an activity, you have to navigate to the Related Records tab to see the parent record, in this case Incident 1268. Again, easily remedied by adding these fields to the main tab with a bit of configuration.

We get so conditioned into using the Work Order Tracking application that we tend to ignore the Activities and Tasks application. But it does have unique functionality that doesn’t exist in Work Order Tracking. For example, you can add a classification and specification, failure report, and log notes directly against a task, you can of course do this for an activity.

What you cannot do in the Activities and Tasks application is create a new record, add safety details, or perform actions that will build a hierarchy (except tasks), for example there is no action for Create Work Package, Apply Route, and there is no Child table window.

Solution Details

The Solution Details tab has long description fields for Symptom, Cause and Resolution. You can either pick an existing Solution at ACTIVE status or you can enter directly in the three long description fields. Each long description field has the Rich Text Formatting (RTF) toolbar. When picking a solution, a Crossover Domain called SOLUTION copies over the three long description fields, and this will overwrite anything which you have already entered.

Only one solution can be applied to an Incident or Problem, it can be overwritten with another. If it is blanked the text from the previous solution is retained in the three long description fields. These fields can always be modified they are not tied to the descriptions in the Solution record.

At the bottom of the Solution Details tab, you can see any attachments associated with the chosen Solution. 

The Self-Service Access checkbox is on the Incident record and when checked will make the solution visible on the Self-Service Service Request. There is a similar field on the Solutions application, but it is not copied to the Incident when the solution is applied. You can easily add it to the crossover domain if you want to default it, but it may be better for the Incident owner to make that decision.

There is an action Search Solutions which makes it easier to find a solution to use on the Incident record. 

I’ve added a classification on the Incident record for 1 \ 105 \ 10501 – End User Issue \ Network \ Connection. Notice that the Incident’s description has changed, this is due to the Description Generation feature of Classifications.

The Search Solutions dialog uses the Incident’s classification to perform the search. When using the three ticket-based applications and solutions it is quite normal to add all four objects in the Classifications – Use With table. 

The search will also perform a hierarchy search so for example you could search for all solutions that were End User Issues \ Network – don’t forget to use the Find button.

The Solution Description field should search on the short and long solution description, and the long descriptions of the Symptom, Cause and Resolution. Unfortunately, it doesn’t allow a search on anything, and a case has been raised with IBM Support. It works OK in the Service Provider version of this application.

Only Active solutions are found by the Search Solutions action.

I have blanked the Solution field and overwritten the previous text for Symptom, Cause and Resolution. There is a Create Solution action that will create a solution record from what you have written. The Create Solution action is not available from the Service Requests application.

After using the Create Solutions action in the Solutions application you can see that the Classification, Description and the Symptom, Cause and Resolution descriptions have been copied. The Description’s long description is not copied. The solution is at DRAFT status. The problem owner may verify the text and supplement the descriptions, perhaps with external links, documents or videos that give instructions on what to do when the solution is being applied to resolve an issue.

There is a hidden YORN field HASSOLUTION which is populated when an Incident has a solution.

Failure Reporting

The Failure Reporting tab will look familiar to those who use the Work Order Tracking application, and it works the same way. I had entered asset 11430 to the Incident and it defaulted the Failure Class PUMPS, not appropriate to a network connection issue I know, but then this is only a test.

You navigate down the failure hierarchy selecting the failure codes for the Problem, Cause and Remedy levels, or returning without a remedy, if only the cause is relevant. A textual failure report can be entered in the Remarks long description and there is a field for the date of the failure report, Remarks Date.

The INCIDENT record has a few hidden fields, PROBLEMCODE, FR1CODE and FR2CODE fields, that store the Problem, Cause and Remedy making it easier to create KPIs or reports without doing complicated subqueries to the FAILUREREPORT table. These fields and the FAILURECODE exist on the SOLUTION table, but they are not populated when you use the Create Solution action from the Incidents application. 

Problems Application

From the Incidents application I have used the action Create Problem and Problem 1267 was created. From the screenshot you can see the same tabs as there are in the Incidents application, including Activities, Solution Details and Failure Reporting. From the Related Records tab you can see the Originating Record is Incident 1268.

The top of the main Problem tab has the same field layout as for Incidents.

The only difference is a field that you can see towards the bottom of the main tab, a check box – Is Known Error.

There is also a hidden field ISKNOWNERRORDATE which I have added to the Dates section. This is populated when the Is Known Error attribute is checked.

Duplicate Ticket

When you use Duplicate Problem and there are no Activities then you get a message at the top of the screen to say that the record is duplicated, and the new duplicated Problem record is loaded, and you would then need to use the Save button.

Note. The Incident had one activity, and this was not copied to the Problem record when the Create Problem action was used.

I’ve manually added two activities using the New Row button and T1260 and T1261 were created.

Now when you use the Duplicate Problem action a dialog opens with a radio button with choices to Duplicate Problem or Duplicate Problem and Activities. I chose the latter and the two activities were created on the duplicated Problem record.

There is an attribute called DUPFLAG with a synonym domain PROBLEMDUPFLAG. For Incidents the domain is called INCIDENTDUPFLAG and for Service Requests it is SRDUPFLAG. Each domain has two options DUPLICATE and DUPTKACT – Duplicate Ticket and Activities. It controls the setting of the radio button.

When you duplicate a ticket:

• No related tickets or work orders are duplicated
• No work log is duplicated
• No date fields are duplicated
• The originating record ID and class are not duplicated
• No solution details are duplicated
• Only the failure class and problem code of a failure report are duplicated
• The Multiple Assets, Locations and CIs records are duplicated

Incidentally, while Service Requests do not have an Activities tab or table window, a Service Request may have child activities and when it does the dialog appears when using Duplicate Service Request.

Delete Ticket

The rules for deleting a ticket are quite restrictive. On the Incidents application I came across the following error messages:

• “BMXAA4308E – This ticket cannot be deleted because it is no longer in a status of New or Queued. The ticket can be closed via the Change Status action.”
• “BMXAA4302E – This ticket cannot be deleted because it has child activities. Remove the child activities and try again.”
• “BMXAA4303E – This ticket cannot be deleted because actual labor transactions occurred for the ticket.” This did not occur if you have only started the timer.
• “BMXAA4305E – This ticket cannot be deleted because it is a global ticket and referenced by other records.” 
• “BMXAA4310E – This ticket cannot be deleted because there are work log entries associated with it.”
• “BMXAA4304E – This ticket cannot be deleted because there are communication log entries associated with it.”
• “BMXAA4620E – Cannot delete because it is, or had at one time been submitted to workflow.”
• “BMXAO0195E – “This ticket is related with another record, so it cannot be deleted.”

The last error message is because the Incidents application that I am using is one which is provided with the HSE add-on. In the Messages action that you can find in the Database Configuration application there are a few other Ticket messages associated with deleting a record:

• “BMXAA4306E – This ticket cannot be deleted because it has led to the creation of another record, and that linkage cannot be deleted.”
• “BMXAA4307E – This ticket cannot be deleted because it has related tickets, or is listed as a related ticket on another record.”
• “BMXAA4309E – This ticket cannot be deleted because it presently is part of a workflow process, or has been in the past. The ticket can be closed via the Change Status action.”

You may find you receive one of the above messages when deleting a ticket, perhaps other I could not find.