Tips & Tricks with JSM - Escalations in JSM

[#1]

Hi all,

I'm kicking off a new series called "Tips and Tricks", and I’d love for others to contribute. The idea is to share helpful insights and small discoveries we’ve made as admins and architects—things that could benefit others in the Atlassian ecosystem.

For the first post, I’m highlighting a useful feature I recently implemented involving Jira Service Management’s Escalation functionality.

In JSM, customers using the portal have the option to escalate an issue.

Behind the scenes, this action simply transitions the issue to a status labeled "Escalated."

Whether escalated issues receive additional attention depends entirely on how you've configured workflows and automation for the Escalated status.

Here are a few key considerations regarding this status:

• Use is optional: If you remove the "Escalated" status or the transition to it, the escalation option will no longer be available to customers through the portal.

• Functionality varies by organization: Some teams use this status primarily as a customer-facing acknowledgment, without changing how the issue is actually handled.

• Maximizing its value: For teams that want escalation to trigger meaningful action, consider implementing the following:

  • Set up a dedicated queue for escalated issues that is actively monitored by senior support engineers.

  • Configure email notifications to alert key stakeholders when an issue is escalated. This can be achieved via filter subscriptions, workflow post functions, or automation rules.

  • Build filters and dashboards to track escalated issues in real time and support proactive follow-up.

By designing your workflow around the escalated status with intention, you can ensure escalations lead to appropriate visibility and action.

It's often said that everyone thinks their issue is the highest priority—leading to frequent and sometimes unwarranted use of the escalation feature.

To help manage this, here’s a simple trick:

You can control when the escalate option is visible to customers by placing conditions on the transition to the Escalated status. This allows you to introduce logic that governs when escalation is actually available.

For example, a client once asked:
“Can we allow customers to escalate a ticket only if it’s been open for more than 2 days and is currently in the ‘Waiting for Support’ status?”

Here’s how I addressed the request:

1. Create a Custom Field:
   I created a custom field named Escalatable. I chose a Number type for simplicity and clarity—though other field types such as text or select lists would also work. I preferred numeric values due to their straightforward logic and compatibility with automation conditions.

2. Configure the Transition Condition:
   On the transition from “Waiting for Support” to “Escalated,” I added a Value Field condition that checks if the Escalatable field equals 1. While this field defaults to 0 (indicating not escalatable), setting a default isn’t strictly necessary—since an unset (null) field does not equal 1. That said, I still prefer explicitly assigning a value.

   Although the field doesn’t need to appear on any screens, I chose to add it to both the issue type’s screen and the agent view. I find it helpful for agents to easily see whether an issue is eligible for escalation.

3. Set Up Scheduled Automation:
   I created a scheduled automation rule to evaluate issues nightly (using the CRON expression 0 0 * * * for midnight). This rule targets all relevant Service Request issue types in the project, checking if they are at least two days old and still unresolved.

   The rule updates issues where Escalatable is either 0 or unset (EMPTY), setting the field to 1 when conditions are met. I included the EMPTY condition to account for edge cases where default values might not be properly set.

   JQL Example:

   created <= -2d 
   AND issuetype in ("[System] Service request", "[System] Service request with approvals") 
   AND resolution IS EMPTY 
   AND "Escalatable" in (0, EMPTY)
   

And this would be a sample of the automation.

“Delayed escalation for 2 days” is just one example use case—the escalation transition can be configured with any parameters you need. If you’d like help setting up your escalations or need assistance with anything else in the Atlassian ecosystem, please feel free to reach out to me directly.