3 Replies Latest reply on Jan 2, 2014 8:56 AM by Nicholas Wanke

    How are callbacks prioritized? Or is there an option to have them grouped by incident and restoration time?

    Ryan Moore

      My system operators have noticed that sometimes when doing callbacks they get to some calls that were part of an outage that was restored a couple hours ago.  It appears that the callbacks don't stay in order with the incidents they were associated with.

        • Re: How are callbacks prioritized? Or is there an option to have them grouped by incident and restoration time?
          Nicholas Wanke

          Hi Ryan

           

          The simplest answer here is that it's configurable, with priority groups generally being set by Customer 'Critical' status.  See below for some more details.

           

          This configuration is in Miner.Responder.DataServices.exe.config towards the bottom, after the '<CallbackConfig' tag.  Callback configuration is grouped by 'scenarios', which are basically just sets of callback rules.  At any one time, only one scenario is active and being used.  This scenario sets which Callback 'Events' will generate callbacks (such as Incident Restoration or Incident Expected Restore Time Defined), and each Callback 'Event' has a list of 'WhoToCall' (such as OnlyRequests or AllAffected) values, grouped by customer criticality (and given a priority).  So, in the example I sent below, this is the 'critical' scenario in our out of the box configuration.  If this is set as the current callback scenario, incidents get created as soon as an incident is created that takes a customer out of power (and this is the only event that will generate callbacks).  Any affected customer with a critical status of 1, 2, 3, or 4 will be generated as soon as they are out of power.  The priority order will start with those with a critical status of 1, then 2, and so on through 4.  Please let me know if you have any other questions.

           

          <Scenario Name="critical">

                  <CallbackEvents>

                    <CallbackEvent Name="IncidentCreated" Type="Miner.Responder.Processors.Callback.CallbackOnPowerOut" CallReasonCode="3">

                      <CallList WhoToCall="AllAffected" Critical="1" Priority="1" />

                      <CallList WhoToCall="AllAffected" Critical="2" Priority="2" />

                      <CallList WhoToCall="AllAffected" Critical="3" Priority="3" />

                      <CallList WhoToCall="AllAffected" Critical="4" Priority="4" />

                    </CallbackEvent>

                  </CallbackEvents>

                </Scenario>

          1 of 1 people found this helpful
            • Re: How are callbacks prioritized? Or is there an option to have them grouped by incident and restoration time?
              Ryan Moore

              Thanks for the help, I was able to find more information in the resource center (with your post's help on what to look for).  I've done some more testing and this is the behavior I've noticed using the default configuration.  Outage callbacks are grouped in the RX_Callbacks table by incident id sorted by incident id.( IE older incident callbacks are listed listed first).  However, when doing the call backs through the Responder web page the call backs seem to appear based on the original call time (IE the oldest calls come up for call backs first).

               

              For example:  Incident 1 had two calls, 10:30 (Call#1) and 10:40 (Call#2) respectively.  Incident 2 had two calls at 10:35 (Call#3) and 10:45(Call#4).  If both incidents get restored before any call backs are started, the callback order in the Responder web page appears to be Call#1, Call#3, Call#2, Call#4.

               

              What our operations manager would like is the callbacks to be grouped by Incident and ordered by Restoration time in ascending order.  So in the previous example if Incident 1 was restored at 11:05 and Incident 2 was restored at 11:00, the callback order would be Call#3, Call#4, Call#1, Call#2.

               

              Grouping the callbacks by incident is probably the most critical since you could have a situation where the last call on Incident 1 comes in 3 hrs after the original call. If there are other restored incidents with callbacks required, that came in before the last call on Incident 1, they would have to be done before you'd get to the final callback on Incident 1 (which could potentially be hours later if there were a lot of incidents with callbacks during that 3 hr window).

               

              I'll submit an incident with support to see if this is possible.