How case escalations work in ServiceNow

[Todd Preece]

On occasion, an end-user may not get the attention or urgency that they would like on a case they've submitted and agents/operators find themselves on the receiving end of an "I want my issue escalated" request. I found myself wondering how that even works w/in ServiceNow so dug into how that workflow actually works.

Turns out an out-of-the-box escalation workflow only exists in 3 places, HR Service Delivery, Workplace Service Delivery, and CSM. How it works in them is slightly different so here are a couple of diagrams to make your understanding and setup/configuration a bit easier.

Within HRSD and Workplace Service Delivery the processes are largely identical.

1. An agent receiving an 'escalate my case' request leverages the escalation UI action link in the case form and fills out a simple text field on the reason.
2. The escalation rule table is simply a set of records defining the "from" and "to" assignment groups. Think of this as a record indicating that if the current assignment group is Tier1 then the escalation group is Tier2.
3. Submission of the escalation form in step 1 simply leverages the escalation rule to re-assign it. 
4. If the case had previously been assigned to a person, it will be reassigned to a person in the escalation group. If the case had not been assigned to a person, the assigned to is left blank after reassignment.

 

Within CSM, as you can see above, the process is far more robust with a lot more moving parts.

1. An agent receiving an 'escalate my case' request leverages the escalation UI action link in the case form.
2. That form contains quite a bit more than the simple text field you saw in HR/WP. Details of that form are shown in the diagram above.
3. After submitting the escalation form 2 parallel paths are taken
4. 1. An escalation record is created and linked to the original case record. Escalation records can contain SLA's, watchlist and other associated workflows as relevant to your organizational processes.
   2. An escalation template is referenced as it was defined in the escalation form which among other things defines whether approval is required for the case to be escalated or not. If approval is not required the the case is flagged, if an approval is required its sent to the group defined in the template.
5. Should the case be flagged, the case receives a pretty little color enhancement to make it more obvious to the agent that attention needs to occur. See image below for how that looks in both the classic UI and agent workspace.
6. Finally, once the escalation is appropriately dealt with the agent can leverage a 'Deescalate' UI Action now present on the case form. This closes out the escalation record and unflags the case.

Hope this helps!

[peter_repan]

Hi @Todd Preece 

Is it possible to define Escalation rules with multiple groups? 

For example I have escalation rules for :

• HR Tier 1 > HR Payroll
• HR Tier 1 > HR Benefits
• HR Tier 1 > HR Talent Management

And I want agent to select which group should be used for escalation from "HR Tier 1". But when click on "Escalate Case" action in workspace, the popup in workspace only shows "Work Notes" and does not allow me to pick a group. This is for me totally weird, I'm only able to define one group for escalation? 

[Todd Preece]

@peter_repan Sorry for the delay, just saw your comment. I did a bit of playing around and seems as though the escalation logic is linear only (e.g. Tier 1 -> Tier 2 -> Tier 3). Like you, I tried to create multiple escalation rules for Tier 1 to see what would happen but it only looked at 1 rule and ignored the others. So yes, looks like you can only define 1 group.

Got me thinking about how you could create a new/modified UI action with a flow and decision table behind it and then realized the LOE was far more than just re-assigning the case. 😉 

[Ryan Downey1]

@Todd Preece @peter_repan I am working on a similar need for HR. I created a near replica of the OOB Escalate case UI action on the HR case table. All I did want remove the conditions. I then created a replica of the OOB ui page the UI action is referencing and updated the gliderecord that references the sn_hr_core_tier_definition. That is the table the OOB UI action utilizes. I added a condition field to that table so I could build conditions into the escalation rules. I pasted the code below that I used within the UI page process script incase you want to utilize it as well. 

My only hang up right now is I can't seem to figure out how an HR manager knows a case has been escalated. There looks to be an escalation counter on the table but it doesn't update.

function escalateCase(task) {
    var gr = new GlideRecord('sn_hr_core_tier_definition');
    gr.addQuery('escalate_from', task.assignment_group);
    gr.addNotNullQuery('escalate_to');
    gr.query();
    while (gr.next()) {
        var cond = GlideFilter.checkRecord(task, gr.u_escalation_criteria);
        if (cond == true) {

            task.assignment_group = gr.escalate_to;
            task.assigned_to = '';
        }
    }
}

[st333]

how to link more than one escalation to an account? 

This field is a reference field on account form and there is no way to associate more than one escalation to an account. Shouldn't this be a list field? have i understood escalation feature wrong?

[Vaniyaa]

Hi  @peter_repan and @Todd Preece ,

Just wanted to know did you got any solution for how to define Escalation rules with multiple groups.

Thanks,
Vaniyaa.