Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

An alternative way to set Priority using Impact / Urgency matrix via smart variables

Boris Zozoulia September 16, 2021

Hello Community

My company has recently had a case when we needed to derive a priority using a rather complex Impact / Urgency matrix.

There is always a way to create a long-running set of if-else conditions in the automation, however, depending on the complexities in your impact/urgency definitions, this set can be really long (hard to maintain) and can exceed the maximum allowed number of components in the automation. And you will need to create a number of these automations to finish this task.

We have come up with an approach where only 5 components are required to derive the priority of the "unlimited number" of impact/urgency combinations.

Some theory first:

Jira stores priorities in a format of id/name pairs.

For simplicity, I will be referring to the priorities in this post by numbers, where

  1. 1 - Critical
  2. 2 - High
  3. 3 - Moderate
  4. 4 - Low

A similar approach applies to two custom fields we have created for urgency and impact, where these fields can be either of these values

  • 1 - Critical
  • 2 - High
  • 3 - Moderate
  • 4 - Low

As you can see - impacts and urgencies values are prefixed by a number which makes it easier to operate within the automation later.

Below is the sample matrix of impact and urgency resulting in the priority.

The priority value is shown by colour, where red - priority is 1, orange - 2, yellow - 3, and green - 4.

It is possible you might have other priorities like 5, and 6 - but it does not matter, since the approach will work for any number of. 



The numbers in the coloured cells are sequential and serve a purpose to "address" the priority value in the list of priorities which can be defined as a priority sequence:



  • 0th element corresponds to (i1/u1) with the value of 1 - Critical
  • 1st element (i1/u2): 1 - Critical again
  • 2nd (i1/u3) is 2 - High
  • 3rd (i1/u4) is 3 - Moderate 
  • ...
  • 15th (i4/u4) is 4 - Low

(total 16 elements with 0 based index)

To get the "address" of the priority we need to use the following formula:

(Impact+Urgency) + ((Impact-1) * (NumberOfColumns-1)) - 2

Where NumberOfColumns represents the number of Urgency values, in our case we have 4.

Quick test:

Impact = 3
Urgency = 2
priorityAddress = (3+2) + ((3-1) * (4-1)) - 2 = 5 + (2 * 3) - 2 = 9

9th address in the prioritySequence above is 2 (2 - High) - orange colour

sequence: 1 1 2 3 1 2 3 4 1 2 3  4  2  3  4  4
address : 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

Putting it all together

The whole automation to calculate the priority consists of a trigger, issue scope and 5 components:

  1. When: Field value changed for Impact, Urgency during Create issue/ Edit issue
  2. Issue field condition: Issue type is one of Incident, Problem
  3. Create variable: prioritySequence = 1,1,2,3,1,2,3,4,1,2,3,4,2,3,4,4
  4. Create variable: priorityAddress = {{#=}}{{impact.value.left(1).asNumber}} + {{urgency.value.left(1).asNumber}} + ({{impact.value.left(1).asNumber}} - 1) * 3 - 2{{/}}
  5. Set entity issue property: priorityCell = {"address": {{priorityAddress}}}
  6. Create variable: calculatedPriorityValue = {{prioritySequence.split(",").get(}}
  7. Edit issue: Do not choose fields but set Additional fields
"fields": {
"priority": {
"id": "{{calculatedPriorityValue}}"

There are few things to note:

  • Every time when you create a smart variable - it is created as String, not as a number. 
  • Line 4: Uses math smart values and parses impact and urgency fields, where it takes 1 leftmost character from the field value (which is going to be a digit) and converts to actual number via asNumber function.
    For simplicity in my case, I have prefixed all field values with numbers, but in your case, when it is not possible, you can map your values to a number somehow.
  • Line 5: Uses entity properties, since smart variables cannot be used as function arguments, as noted by @Bill Sheboy  in
  • Line 6: gets a derived priority value from the list created on Line 3, via the issue property value set on the previous line.
  • Line 7: Uses "advanced" filed value setting approach, since choosing the filed to set, does not allow using smart values.

I hope the above post will help someone to limit the number of automations, components inside the automation in their JSM implementations.

This approach can be used for defining some additional logic for your automations, since the addressed cell values, can be a "trigger" or business rule "input" into your if/else branches - extending the logic of automations.



Log in or Sign up to comment
AUG Leaders

Atlassian Community Events