Enable Escalate Action in ServiceNow

 

Enabling the OOTB Escalate Action in ServiceNow Security Incident Response

ServiceNow Security Incident Response (SIR) includes an OOTB Escalate capability that can transfer a Security Incident from its current assignment group to a predefined escalation group.

I recently had a requirement to implement the following escalation path:

SIR Analysts → SIR Managers

At first glance, this might require a custom Workspace action, Flow, or Business Rule. Fortunately, SIR already provides the functionality. The main task is to understand what controls the Escalate action and configure the appropriate escalation path.

In this article, I'll walk through how the OOTB functionality works, what makes the action visible, and how to configure and test it without customizing the underlying ServiceNow code.

The requirement

The use case was straightforward:

As a SIR Analyst, I want to escalate a Security Incident when additional expertise or support is required, so that higher-risk or more complex incidents receive the appropriate level of investigation and response.

For the MVP, the agreed escalation path was:

Analysts escalate to Manager

The goal was to use as much OOTB functionality as possible.

Finding the OOTB Escalate action

ServiceNow already provides an Escalate UI Action for the Security Incident table:

Security Incident [sn_si_incident]

The interesting part of the UI Action isn't the button itself, but its Condition.

The condition ultimately invokes:

new sn_sec_cmn.SecurityCommonClientUtils().showEscalateButton(current, uri.get('sysparm_view'));

This means the visibility of the Escalate action is controlled by the OOTB SecurityCommonClientUtils Script Include.

Looking at showEscalateButton() reveals how ServiceNow determines whether escalation is available.

Conceptually, the relevant logic is:

showEscalateButton: function(current, view) {

    if (!gs.hasRole(this.SN_SEC_CMN_READ_ROLE)) {

        return false;

    }

    if (view == 'security_itil')

        return false;

    if (view == 'nonit_security')

        return false;

    var gr = new GlideRecord('sn_sec_cmn_escalation');

    gr.addQuery('initial_group', current.assignment_group);

    gr.query();

    if (gr.next())

        return true;

    return false;

}

This tells us something important:

The Escalate action is driven by configuration.

There is no need to create a custom action simply to implement a group-to-group escalation path.

What makes the Escalate action available?

There are three important conditions.

1. The user must have the required role

The Script Include checks: 

gs.hasRole(this.SN_SEC_CMN_READ_ROLE)

The exact role represented by SN_SEC_CMN_READ_ROLE should be verified in the Script Include for your ServiceNow release/version.

This is also why testing as admin alone isn't sufficient. Test with the actual SIR analyst persona that will use the functionality.

2. The Security Incident must be opened in a supported view

The OOTB implementation explicitly excludes these views:

• security_itil
• nonit_security

Other applicable views continue to the escalation configuration check.

3. An escalation path must exist for the current assignment group

This is the most important condition.

ServiceNow queries: 

sn_sec_cmn_escalation

using the Security Incident's current assignment group:

gr.addQuery('initial_group', current.assignment_group);

In other words, for an incident assigned to SIR Analysts, ServiceNow looks for an escalation configuration whose Initial Group is SIR Analysts.

If one exists, the incident becomes eligible for escalation.

Configuring the escalation path

The solution therefore requires configuration rather than customization.

Navigate to the Security Operations escalation configuration:

and create an escalation path such as:

sn_sec_cmn_escalation

Initial group (CDC Analysts) ==> Escalation group (CDC Managers)

Once saved, Security Incidents assigned to CDC Analysts satisfy the group-related condition used by showEscalateButton().

No modification of the OOTB UI Action or Script Include is required.

Testing in SIR Workspace

The next step is to test the configuration using the same experience that analysts actually use.

Open a Security Incident in SIR Workspace and make sure its assignment group is:

CDC Analysts

The OOTB Escalate action should now be available from the incident actions.

In my test, the action appeared as expected for an incident assigned to the configured initial group.

The escalation dialog

Selecting Escalate opens the OOTB escalation dialog.

The current group is displayed and the analyst is prompted to select an Escalation group and provide a mandatory Reason.

This is another reason not to build a custom modal or Workspace action prematurely—the standard functionality already provides the user interaction needed for the use case.

What happens after escalation?

Submitting the escalation transfers the Security Incident to the selected escalation group.

In my test, the incident changed from:

Assignment group: CDC Analysts

to:

Assignment group: CDC Managers

The resulting incident also had an appropriate Assigned to user in the new group.

Note: it's worth validating state and assignee behavior in your own instance rather than assuming they will always behave identically. Assignment rules, flows, business rules, or other SIR configuration can influence what happens after the group changes.

Why does the Escalate action disappear afterward?

An interesting consequence of the OOTB implementation becomes obvious once you understand showEscalateButton().

Before escalation:

Security Incident

Assignment group = CDC Analysts

        ↓

sn_sec_cmn_escalation

Initial group = CDC Analysts

        ↓ MATCH

Escalate = visible

After escalation:

Security Incident

Assignment group = CDC Managers

        ↓

sn_sec_cmn_escalation

Initial group = CDC Analysts

        ↓ NO MATCH

Escalate = not visible

In my configuration there was no further escalation path whose Initial Group was CDC Managers, so the OOTB Escalate action was no longer available after the incident was transferred.

That's expected behavior based on the OOTB visibility logic.

It also means you can potentially configure multiple escalation stages if your process requires them.

For example:

CDC Analysts ==> CDC Managers ==> Senior Incident Response Team

Each stage would need the appropriate escalation configuration.

Don't customize the UI Action unnecessarily

The biggest takeaway from this implementation is simple:

Check the OOTB escalation configuration before building a custom escalation solution.

It would be relatively easy to create a custom Workspace action that changes assignment_group, but doing so would duplicate functionality already provided by SIR.

For this requirement, I would avoid modifying:

OOTB Escalate UI Action

        ↓

SecurityCommonClientUtils

        ↓

OOTB escalation dialog

Instead, configure:

sn_sec_cmn_escalation

This keeps the implementation much closer to OOTB behavior and reduces the amount of custom code that has to be maintained through future upgrades.

A useful troubleshooting checklist

If Escalate isn't appearing for a Security Incident, I would check these items first:

1. Assignment group - Is the incident assigned to a group configured as an initial_group in sn_sec_cmn_escalation?
2. Escalation configuration - Does the expected Initial Group → Escalation Group relationship actually exist?
3. User role - Does the analyst satisfy the SN_SEC_CMN_READ_ROLE check?
4. View - Is the incident being displayed using one of the views explicitly excluded by the OOTB Script Include?
5. Workspace vs platform UI - Test using the actual SIR Workspace and persona that will use the functionality.
6. Test as the analyst - Don't rely exclusively on testing as admin.

I would also inspect the OOTB implementation before changing it. The showEscalateButton() method provides a very useful starting point because it tells you exactly why ServiceNow considers an incident eligible for escalation.

TLDR

For a requirement such as:

CDC Analysts → CDC Managers

ServiceNow Security Incident Response already provides most of what is needed.

The implementation boils down to:

Configure escalation path

        ↓

Initial Group = CDC Analysts

        ↓

Escalation Group = CDC Managers

        ↓

Open an incident assigned to CDC Analysts

        ↓

Escalate becomes available

        ↓

Select CDC Managers + provide reason

        ↓

Submit escalation

        ↓

Incident ownership moves to CDC Managers

The important discovery is that the OOTB Escalate action isn't simply controlled by a role or a hard-coded condition. Its availability is tied to the current Security Incident assignment group and the escalation paths configured in sn_sec_cmn_escalation.

For this use case, the final solution classification is therefore pleasantly simple:

OOTB + Configuration

And that's generally a much better place to end up than another custom UI Action to maintain.

That's a wrap!