1 of 1 people found this helpful
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.
<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" />
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.
That does sound like it makes sense for your workflow.
My thought is that if we'd do this, we'd likely want to make it configurable, as this would be changing the order of callback processing on functionality that has been this way for a long time (so if a client is used to how this works and doesn't want it to change, we might not want to change it out from under them). So we'd likely add a configuration option to toggle between the current functionality and what you are describing above. Thanks for all the detail.