3 Replies Latest reply on Jan 12, 2017 6:30 AM by Julian Wigman

    Incident Management Escalation process

    smemmi Rookie

      Hi all,

       

      I am new to LANDesk and have been asked to develop a change to our current escalation process in Incident Management. Currently if you were to escalate and Incident you would simply click the "Escalate Incident" option once a ticket has been raised and add the escalation details into a textbox, which would then be attached to the ticket. We require something a little more complex:

       

      • Incident can only be escalated once it has passed the breach date
      • There should be multiple levels of escalations (Levels 1-8). Each time an escalation is made the level should go up. Escalations levels can only go up a level, not down
      • Escalations should have an owner assigned to it
      • Each time an escalation level is made the time and date should be recorded

       

      As a LANDesk process designer novice i have questions of what the best practices are to implement this. So do I implement the Escalations as collections? Can you limit the amount of collections per ticket? Should the escalation level just be an ordered list? How would the process check what escalation level it is on?

       

      Has anyone had to make any similar type of escalation process and if so some advice would be greatly appreciated. Thanks in advance

        • 1. Re: Incident Management Escalation process
          michael.odriscoll SupportEmployee

          Hi Suresh

           

          Thanks for posting this to the Community.

           

          Were you able to gather any further information on this subject? If you think there is something worth sharing, please post it here. You might help someone out.

           

          Michael

          • 2. Re: Incident Management Escalation process
            smemmi Rookie

            No still haven't had any responses for this

            • 3. Re: Incident Management Escalation process
              Julian Wigman Master

              Hi

               

              Does the "Escalate Incident" action currently create a collection object or is it just a windowless action that precedes an automatic action to set an attribute value on the main window:  there are obviously various starting points on where you are at right now.

               

              There is already an "IsBreached" Boolean attribute on the "Incident" top-level object that the system will set to TRUE when the Response Level Escalation breaches so this can be part of the solution.

               

              So I would suggest the following approach noting you may already have some of this in place in terms of object design:

               

              1. Create a new collection "Incident Escalation" object with "no-deletion" type under "Incident Management" module witch the following attributes:

              • Create Date:  Datetime, persistence type
              • Update Date:  Datetime, persistence type
              • Create User:  User Related, persistence type
              • Update User:  User Related, persistence type
              • Summary:  String(100), IsName
              • Details:  String(-1)
              • Owner: User Related

               

              2. Drop the "Incident" object onto this and say YES to the pop to create a collection of these on Incident.  Switch to Incident tree and rename this object etc if needed (for Example I do this for best practice).  Also right-click and select "Manage Action" and give it a name something like "Escalate Incident".

               

              3. Create a new window for this new object. Make "Summary", "Details" and "Owner" mandatory.

               

              4.  In your process, add this action at whichever statuses where you want this to be available.  It will need to be a "process action" rather than an "optional action" as we need to make it available only at certain times.  In your process you should see examples of this around the Add Note action;  it does some "magic" and then returns to the status it was invoked from.

               

              5.  Add a precondition calculated condition in front of the action so that it is only available:

                   a) When "IsBreach" = true,  AND

                   b) The count of items in the collection < 8

               

              The calculation for the precondition will be something like this in structure but of course substituting your objectname instead:

               

              import System

              static def GetAttributeValue(Incident):

                  if Incident.IsBreached == true and Incident._IncidentEscalations.Count < 8:

                     return true

                  return false

               

              This will only make the "Escalation Incident" action available if the Incident has breached AND the current count of escalations on this Incident is less than 8 (it'll hide the action once eight escalations are added).

               

              So at each status, ie "In Progress", "With Customer" etc you will have a mini-loop of StatusX -> Precondition -> Escalate Incident -> StatusX.

               

              The user you assign the escalation too will be mandatory on the Escalation window (as was the "Owner" field I suggested above) and the data created automatically part of the collection.  You will also see in the Audit trail for date/user invoking the action.

               

              6.  Add the collection tab to the bottom of the main Incident window(s).  Also create a Default Query for this object to format the tab contents

               

              7.  Might be nice to also have a calculated attribute (BEFORE SAVE type with dependency set to your new escalation collection) that simply returns the current escalation Level;   Just make this a calculation that returns Incident._IncidentEscalations.Count (or whatever the object is called).

               

              That's how I'd approach anyway.

               

              Regards

               

              Julian Wigman

              MarXtar Ltd