Understanding Escalation Points and setup escalation to cancel a Service Request

Here is  a document from IBM on setting up an escalation to cancel SR.  It’s a pretty straight forward example and I normally probably wouldn’t post it as I have already written about setting up escalation points before, but in my example, I used the ‘getdate()’ SQL method to calculate which records were not processed the last time the escalation ran.  The reason for this post is to get  a better understanding of escalation points and how to use them.  This tutorial from IBM gave me a better understanding of how the escalation points worked.

So here is my basic understanding of how it works.  For every escalation condition, you can create a generic SQL statement to query a bunch of records, for example, you want to query all work orders that were cancelled and had generated an SR.  The query would look like this:

exists ( select 1 from workorder where origrecordclass LIKE '%SR%' and
origrecordid= sr.ticketid AND status= 'CAN')

Now you don’t want to your escalation to run against every record returned, so this is where you would narrow down your query by using the escalation points.  Your new escalation point is created with the CHANGEDATE attribute set and the ‘Elapsed Time Interval’, ‘Interval Unit of Measure’ set to ‘1’, and ‘MINUTES’ respectively.  You can also set the ‘Escalation Point Condition’ to narrow your results even more, but mainly, you will use the CHANGEDATE value as a variable to check which records haven’t been processed in the last one minute.  I assume that the time interval and the schedule you run your escalation at, should be equal.  I don’t think it would make sense for them to not be.  So if your escalation point is set to check the CHANGEDATE value every 30 minutes, you would change your run schedule to be the same.

This example from IBM doesn’t show how to use multiple escalation points but you can add as many as you want.  I have looked at the Maximo demo database and they have escalation points on multiple fields such as TARGETSTART, and TARGETFINISH.  They also have a negative value for the time interval.  What does that mean?  A positive value for the time interval means that it will check for dates in the past and a negative value will check for dates in the future.

Hope this helps your understanding of escalation points.  I know it’s helped me!

Did You Know...

As Maximo Experts, we have developed Maximo adds on products to make Maximo work assignment simple, reporting easy, and facilitating service requests seamless. Check out our additional products EZPlanner, EZInsight, and EZRequest.

Find Out More

2 thoughts on “Understanding Escalation Points and setup escalation to cancel a Service Request

  1. Hello Chon

    I’m not sure it works you explained (or I did a mistake). I’m trying to set up an escalation to send a notification to the owner of a ticket if a communication related to the ticket is sent (i.e. a new row in the commlog table is added). I set up the escalation with the condition:

    ownertable in (select value from synonymdomain where domainid=’TKCLASS’) and
    (ORGOBJECT != ‘ESCALATION’ or ORGOBJECT is NULL) and (NULLIF(CREATEBY,(select owner from ticket where ticketuid = ownerid)) is not NULL)
     
    Then if what you are describing is correct I should create an escalation point on CREATEDATE with the condition ELAPSED TIME INTERVAL let’s say of 5 minutes and schedule the escalation to run every 5 minutes.
    Now when I tried it loaded all the records already there even created months before!
    So I need to add a further condition in the escalation point like:
    (SYSDATE – CREATEDATE)*24*60*60 <= 5*60

    Maybe it's done on purpose to that you never loose records. Imaging for instance that you have to set admin mode on. This operation will stop the escalation and if it takes more the 5 minutes to turn admin mode off you will loose some records.

    Best

    Francesco

  2. What happens if Maximo goes down? Wouldn’t that mean if the escalation was supposed to run when Maximo was down, those range of records would not be processed? I think ChangeDate is a good field value to use… but I think it may help to use another field as a flag to know if a record has been processed or not to handle these downtime scenarios.

Leave a Reply

Your email address will not be published. Required fields are marked *