Last Updated on October 29, 2023 by maximosecrets

There are three scenarios where the status could be inherited on a ticket.

• Inherit Status from a Follow-up Ticket
• Inherit Status from a Global Issue
• Inherit Status from a Follow-up Work Order

A ticket can have one or more activities and like there is a rolldown of statuses from a parent work order to its children there is a rolldown of the ticket status to child activities.

To remind ourselves of the different Ticket Statuses they are NEW, QUEUED, PENDING, INPROG, RESOLVED, CLOSED. For a Service Request there are also two synonyms of CLOSED, CANCELLED and REJECTED. There is an article on this subject which you can find here: http://maximosecrets.com/2021/10/21/ticket-statuses/

A ticket can also be related to other tickets. The relationship types are FOLLOWUP, ORIGINATOR, RELATED, ISGLOBAL and RELATEDTOGLOBAL. There is an article on this subject which you can find here: http://maximosecrets.com/2021/10/26/service-request-related-tickets/

At the bottom of this article there is a summary.

Inherit Status from a Follow-up Ticket

I’ve created a Service Request 1309 at NEW status and from this created an Incident 1259 and from this created a follow up Problem 1260. All three tickets are at NEW status. In the Problem application I changed status of problem 1260 to QUEUED and there was no change in status on the originating incident. On Incident 1259 I changed status to QUEUED and the originating record Service Request 1309 was also changed to QUEUED.

The reason why the status change was inherited on the Service Request and not the Incident is due to a hidden field INHERITSTATUS which defaults to 1 on the SR object, and 0 on the INCIDENT and PROBLEM object. The status inheritance only works between the follow-up ticket and the originating ticket and does not occur between two tickets that have a relationship type of RELATED.

Note. There is no similar attribute on the WORKORDER object, a follow-up work order cannot change the status on the originating work order. There is, however, a rolldown of status in a work order hierarchy, and the attribute PARENTCHGSSTATUS controls this.

Each type of ticket has its own Synonym Domain.

• For Service Requests it is SRSTATUS
• For Incidents it is INCIDENTSTATUS
• For Problems it is PROBLEMSTATUS

What would happen if a synonym value was selected for a status attribute that did not exist in the originating record’s synonym domain? The Incident Status has a synonym of QUEUED called WOR – Waiting on Review, which does not exist in the SRSTATUS synonym domain.

I’ve created another Service Request 1310 and from this created a follow-up Incident 1261. On Incident 1261 I am using the Change Status action and selecting Waiting on Review (WOR) which does not exist in the SRSTATUS Synonym Domain.

The result is not what I expected. The status on the Service Request is still at NEW. What I am pretty sure is supposed to happen is that if the status does not exist in the originating record’s status domain list, then it will use the default value for the status level that the follow-up record is being changed to. In our case the Incident Status of WOR is a synonym of QUEUED and that is the default status of the QUEUED level in the SRSTATUS Synonym Domain, so I expected the status of the Service Request to have changed to QUEUED. A case has been raised with IBM Support.

Incidentally I changed status on the Incident to INPROG and the status on the Service Request was also changed to INPROG. 

If the Service Request status had a status of WOR but not at the same level as that on the Incident, then it should not change status to WOR. Status Inheritance will always maintain the same status level between the follow-up ticket and the originating ticket.

The next scenario will look at what happens if there are multiple follow-up Incidents to the Service Request.

On Service Request 1310 I’ve created a second Incident record 1262, and the status is initially set to NEW. I’ve updated the status of the incident to INPROG to bring it in-line with the original follow-up incident 1261. The Service Request and both incidents are at INPROG status.

On both Incident records I have changed status to RESOLVED, but the Service Request has not changed status, it is still at INPROG.

In the second column of the Service Request Details section I have added the Inherit Status Change attribute, and you can see that it is unchecked, which means that the service request will not inherit status changes.

This is doing exactly as expected. When you create a second follow-up record then the INHERITSTATUS field is set to 0, and inheritance no longer occurs.

Inherit Status from a Global Issue

The idea behind a Global Issue is that when there are multiple similar tickets that are referencing the same issue then by declaring that issue as a Global Issue you only then need to manage the ticket that is marked as the global issue and not the tickets related to the global issue. Declaring a ticket as a global issue makes more sense on an Incident or Problem record, but you can also do this on a Service Request.

Ticket Inheritance will flow from the Global Issue to the tickets that have a relationship type of RELATEDTOGLOBAL.

I’ve created a new Service Request 1311 and duplicated it twice to create SRs 1312 and 1313. I declared a Global Issue on Service Request 1311, and related SR 1312 and 1313 to the Global Issue. The relationship type on SR 1311 shows RELATEDTOGLOBAL for both SR 1312 and 1313.

On Service Request 1311 I am changing status to QUEUED. 

Notice that the Change Status action is missing until you activate Edit Mode, the green pencil icon in the toolbar. You may find that Edit Mode has not been enabled on your Service Request application, if it hasn’t the pencil icon will be missing.

After changing status on the Global Issue to QUEUED the two SRs (1312, 1313) which have a relationship type of RELATEDTOGLOBAL, now also have a status of QUEUED.

The same would occur if you changed status of the Global Issue to INPROG, the two SRs related to the Global Issue would inherit their status and be set to INPROG.

If the relationship to the Global Issue is broken by deleting the Related Record marked as RELATEDTOGLOBAL (I’ve done this for SR 1313), then the service request will no longer have status updates from the Global Issue.

Inherit Status from a Follow-up Work Order

Maximo will change the status of an originating service request to RESOLVED when a follow-up work order is changed to COMP, similarly the service request is changed to CLOSED when the follow-up work order is changed to CLOSE.

I’ve created a new Service Request 1314 and from this I’ve created a follow-up work order 1361. When the work order was changed to APPR there was no change of status on the originating Service Request. When the work order was changed to INPRG the originating Service Request 1314 was changed to INPROG. This was not in the original design but there is a System Property mxe.app.workorder.DoNotChangeTicketToINPROG which determines whether to change status on the service request to INPROG when the follow-up work order is changed to INPRG. To have the status of INPRG rolled-down to the service request you will need to set this property to 0. If you want to have the status rolled-down for just COMP and CLOSE, then set this System Property to 1.

I verified that the status is changed to RESOLVED when the work order is changed to COMP and also CLOSED when the work order is changed to CLOSE.

In the next scenario I will change the System Property mxe.app.workorder.DoNotChangeTicketToINPROG to 1. In this scenario we will see what happens if there are multiple follow-up work orders to the service request.

A new Service Request 1315 has been created. From this I’ve created two Follow-Up Work Orders 1362 and 1363. The first thing to note is that the Inherits Status Changes (INHERITSTATUS) attribute on the Service Request has not been changed to zero when the 2^nd follow-up work order was created, (it was changed to zero for the 2^nd follow-up ticket).

Changing the status of work order 1363 to APPR and INPRG did not change the status on Service Request 1315. 

Similarly for work order 1362, at INPRG the status on Service Request 1315 remained at NEW. This is because the System property mxe.app.workorder.DoNotChangeTicketToINPROG is set to 1, meaning that status changes at INPRG will not be rolled down to the originating Service Request.

When I changed work order 1362 to a status of COMP the status of the originating Service Request was changed to RESOLVED, but there was another follow-up work order, 1363, which was still at INPRG status, it had not yet reached COMP. The status of the originating service request is updated to RESOLVED when the first follow-up work order is changed to COMP, and not the last one. 

If this is incorrect then the Service Desk agent can change status on the Service Request back to INPROG and allow it to be RESOLVED when the second work order is changed to COMP.

When the first work order is changed to CLOSE the Service Request is changed to CLOSED. The second work order remains at its previous status, COMP in this case. With the Service Request at CLOSED status, it is not possible to change status to an earlier status, as it is now in history.

For the final illustration in this section, we’ll look at what happens when the follow-up work order to a global issue is completed. Our Global Issue is Service Request 1311. From this I created a follow-up work order 1365, it is currently at status of WAPPR.

When follow-up work order 1365 is changed to a status of COMP the Global Issue, Service Request 1311, is changed to RESOLVED.

The Service Requests that have a relationship type of RELATEDTOGLOBAL to the Global Issue 1311, are also changed to RESOLVED status.

If the Global Issue had a second follow-up Work Order, then there would be no effect on this from a change of status on another follow-up work order. 

Roll Status Down from Ticket to Activities

In this final section I have reset the System Property mxe.app.workorder.DoNotChangeTicketToINPROG back to 0.

I’ve created a new Incident and applied Ticket Template 1004 which has created three activities T1253, T1254 and T1252 at WAPPR status. The Incident is at QUEUED status because there was ownership on the Ticket Template, and this automatically change status to QUEUED. 

When changing status to INPROG there was no change to the status on the activities. However, when changing status of the Incident to RESOLVED the activity statuses were changed to COMP. Similarly changing status on the Incident to CLOSED changed status on the activities to CLOSE. 

A follow-up Service Request to a Work Order will not be updated by a change of status on the work order or service request. Similarly, a follow-up Work Order to a Work Order is not updated by a change of status on either work order.

Summary

There are several ways in which a Service Request may inherit its status from another record. It can be controlled from the attribute INHERITSTATUS which defaults to 1 for Service Requests and 0 for Incidents and Problems.

• A single follow-up ticket to the Service Request. However, if you create a second follow-up ticket from the Service Request, then INHERITSTATUS is set to 0 and the SR will no longer inherit its status from another ticket.
• A Global Issue. If the Service Request has a relationship to the Global Issue with relationship type RELATEDTOGLOBAL.
• A follow-up work order. The status is only updated when the work order reaches COMP or CLOSE status, and INPRG if System Property mxe.app.workorder.DoNotChangeTicketToINPROG is set to 0. The SR status is RESOLVED, CLOSED and INPROG respectively. If there are multiple follow-up work orders the SR status is updated by the first work order to reach the status.

Service Requests with Activities roll their status down at RESOLVED and CLOSED setting the activity status to COMP and CLOSE respectively.

Status inheritance does not occur for relationships of type RELATED or for work orders with a follow-up ticket or work order.

The different classes of ticket each have their own Synonym Domain for the Status field. The classes of Work Orders share the same Synonym Domain. If a ticket has a synonym value that does not exist in the Service Request’s values for Synonym Domain SRSTATUS, then the default value for the same MAXVALUE is used. Note. An issue has been reported to IBM Support, as tests found that no status is inherited if the synonym value does not exist in SRSTATUS.