3 Replies Latest reply on May 15, 2018 1:27 AM by DTurner

    Dynamically set escalation watch

    DTurner Expert

      Hi All,

       

      I have created a Request Offering and the problem is that these records will be subject to an SLA based on when we receive the item - however, certain channels (e.g. email) may result in the item remaining in an intray for a certain amount of time. This time needs to then be added to the SLA once the request has been created.

       

      Within the request, I have a 'Date Received' field which I then use to calculate the difference between the days and subtract that from the Escalation values using a run for child - the problem is that it appears to be overwriting (I think I may need to implement a wait stage, HOP are another can of worms too :s) the value I have set.

       

      Anyone have any experience of implementing something similar?

       

      Thanks

      Declan

       


      Vote here please!: https://ivantiitsm.uservoice.com/forums/904372-service-manager/suggestions/34207696-escalation-variable-trigger-points

        • 1. Re: Dynamically set escalation watch
          DTurner Expert

          UPDATE:

          The escalation engine manages the triggers for this - when looking into it, frs_ops_workflow_timer appears to assign a clock to the SLA schedule (ServiceReq runtime) which is 'locked' after the expiration is reached (then accessible via audit table). frs_ops_workflow_event also appears to be involved but I can't determine much from that other than there are some hexadecimal values associated to it.

           

          So although it would be useful to modify this, I don't think I'll have much luck in doing so; the problem seems to be due to these external clocks; I can't seem to gain control over these and once a trigger is hit, other values on the clock (which may have been updated previously) are reset.

           

          I'll still continue looking into it though - if anyone has any experience in doing so, please let me know

           


          Here's the quick action I used on the escalation clock. This is triggered from a Service Request workflow with an initial 1 minute wait then a run for child:

          $(AddDays(Number(GetSRPValue([ServiceReq#.ServiceReqAssocAllocateEscWatch]RecId,       "sar_datediff")),   L1DateTime))

           

          $(TargetClockDuration +   Number(GetSRPValue([ServiceReq#.ServiceReqAssocAllocateEscWatch]RecId,     "sar_dateDiff")) *   -86400)

           

          This may be difficult to understand but hopefully the picture will help:

          escalation.png

          1) True clock

          2) Modified clock

          3) Clock after true Level 1 escalation

           

          When the quick action triggers, all the clock values are updated (as you can see to the right of 2), including 1 & 3

          Escalations are not triggered i.e. L1, breach actions etc

          Once the first escalation point is triggered (in this example, L1 at 2 minutes), another check is made

          This means that it will not breach until a valid escalation point is hit - as you can see above, 3 is set to 4 minutes (the breach value) yet the clock has only been running for 2 minutes (1)

           

          This escalation engine appears to be ringfenced from us and the above timers appear to be largely for display purposes.

           

          Next, I'm going to set the breach passed/clock state values to see if that changes the process.

           


          I can update the breach passed/clock state values but again, once the first 'true' escalation point is hit, the time spent value is updated and the escalation actions are ran which supports my idea that these are largely display values and are ran by an external process

           

          Probably going to end up creating a standalone workflow process which runs off the escalation dates but not have the escalation send the notifications - likely to be overhead with lots of waiting workflows so I'll have to do some further testing.

          Hopefully my ramblings help someone else on a journey to try and understand escalation clocks, if not, at least I have it written down for future reference

           

          Dec

          • 2. Re: Dynamically set escalation watch
            AlasdairRobertson ITSMMVPGroup

            Looking at the OP could you not alter how the clocks start for the service request?  For example if an SR is created via email then a new status is used "Logged via email" delivery clock doesn't run on this new status. Then only runs once it goes active?

             

            In terms of your workflow on the escalation clocks I would not advise it, as you say its ring fenced and managed but a service, the service runs on a frequency looking for changes to the status of records and then updates the escalation clocks automatically.   If you need to use a dynamic date I would either look at the option on statuses or use the Target Date Time trigger on an escalation clock where you can play with the time calculation as much as you need to and can use the AddWorkingTime functions to introduce the HOP if required.

            1 of 1 people found this helpful
            • 3. Re: Dynamically set escalation watch
              DTurner Expert

              Hi Alasdair,

               

              Thanks for your response - that sounds like what I'll end up doing; the workflows I think are too much overhead and it adds redundancy to the process that provides no value.

              Going to use the secondary clock feature for extensions - so it records the specific extension time - and use the TargetDateTime trigger as you have suggested (totally overlooked this ).

               

              The above just ended up me trying to get my head around how the escalations worked.

               

              Thanks

              Declan