Last Updated on November 19, 2022 by maximosecrets
The three classes of tickets have a similar set of statuses. The status of a ticket can be inherited from a follow up ticket or work order and from a ticket that is marked as a Global Issue.
Ticket Status
The status of Service Requests, Incidents and Problems are similar and can be described together. They each have their own synonym domain and so could deviate if you configure these. The synonym domains are SRSTATUS, INCIDENTSTATUS, and PROBLEMSTATUS.
For all types of ticket, the natural flow through the statuses is NEW, QUEUED, PENDING, INPROG (In Progress), RESOLVED and CLOSED. Two additional statuses for Service Requests are CANCELLED and REJECTED. You can move to CANCELLED status only from the NEW status, and you move to REJECTED status from QUEUED, PENDING and INPROG state. For Incidents there is a status WOR (Waiting on Review) which is a synonym of QUEUED.
The Change Status action provides the ability to enter a memo or change the status date. There are four additional actions for changing the status to QUEUED, PENDING, INPROG (In Progress), or RESOLVED. These would be used if there were restrictions in the statuses that users could move to.
When you first create a Service Request the Reported Date is set to date/time now. Changing the status to INPROG (In Progress) for the first time will set an Actual Start date, changing the status to RESOLVED for the first time will set an Actual Finish date.
At CLOSED, CANCELLED or REJECTED state the Service Request is marked as being in history, and the record becomes read-only, but it will not be filtered out from the List tab records. The action Edit History Service Request allows you to modify history records, and this adds a status history record with a status of HISTEDIT. There are similar actions on the Incidents and Problems applications.
When you first set ownership either by using the action Take Ownership or Select Owner Maximo will move the status to QUEUED except when the status is currently at RESOLVED. Therefore, it is good practise to set ownership early in the process of a service request.
The View History action shows both a status history and an ownership history.
Status Inheritance
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 understand how statuses are inherited it is worth unhiding the INHERITSTATUS field. This YORN field is set to 1 for Service Requests and 0 for Incidents and Problems.
When a Follow-up Incident from a Service Request changes status the Service Request inherits its status from the Incident, INHERITSTATUS = 1, it is allowed. When a Follow-up Problem from an Incident changes status there is no change to the Incident’s status, INHERITSTATUS = 0.
When a change occurs to the Incident status where the status does not exist on a Service Request then the Service Request should change status to the default status at the same internal level as that for the Incident. For example, the Incident status WOR Waiting on Review is a synonym of QUEUED. The WOR status does not exist on a Service Request, therefore the status will be changed to QUEUED instead.
The status inheritance will not jump status levels between ticket statuses. Therefore, if the Service Request did have a status of WOR but at INPROG status level, it would not change to WOR, but would remain at QUEUED, the same status level as WOR in the INCIDENTSTATUS synonym domain.
Note. The INHERITSTATUS field is set to zero if you created a second follow-up Incident to the Service Request, i.e. status inheritance from follow-up tickets stops.
The second scenario is when there is a global issue. When there are multiple similar tickets that reference the same issue then you can mark one of the tickets as a Global Issue. Other tickets that are related to the Global Issue with the relationship type of RELATEDTOGLOBAL will inherit their status from the ticket marked as 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.
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.
The third scenario is when a ticket inherits its status from a follow-up work order. When the work order has a change of status to COMP or one of its synonyms Maximo will move the originating ticket to RESOLVED. For a work order state of CLOSE the originating ticket is changed to CLOSED. There is a System Property mxe.app.workorder.DoNotChangeTicketToINPROG which if set to 0 will also change status of the ticket to INPROG (In Progress) when the work order status is changed to INPRG (In Progress).
If there are multiple follow-on work orders from the same ticket, then when the first one changes status, it will change the status on the originating ticket. If the originating ticket is a global issue, then the status change will be rolled down to the tickets that are related to the global issue. Therefore, completing a work order that was raised to rectify a global issue will move the global issue to RESOLVED and will also resolve all tickets related to the global issue.
If a ticket has one or more activities, then a change of status on the ticket to RESOLVED or CLOSED will change the activities to COMP or CLOSE respectively.
Leave a Reply