Escalate Issue After Fix is Rejected

In this recipe, you will learn how to escalate an issue when the fix has been rejected a certain number of times. This scenario could arise most frequently in a Jira Service Management context where an end user or customer might reject a proposed fix, but the recipe can be applied to any Jira project where there is a threshold for the number of times an issue should be allowed to be re-worked before it is given extra consideration.

There are a few ways in which an issue can be marked as escalated:

  • Set the native Jira Flagged field

  • Set the priority of the issue to a high value

  • Create a custom field for escalations; this method works particularly well when there are multiple types of escalations

  • Create a status for Escalated issues

Note: If you plan to use a specific status for Escalated issues, the Recipe Hold an Issue, Seek Clarification, Then Proceed is a better solution. That recipe can be modified to use a status for high priority issues that require immediate attention.

Using any of the methods above provides powerful options for identifying and working with issues that require immediate attention or that have proven problematic. These include:

The steps below include two options for representing the escalation of an issue. The first uses a custom field called Escalated, which can be either a simple escalation flag (a check box custom field) or a more complicated escalation process that can include multiple escalation types. The second uses the native Jira field Flagged and sets it to true.

Both of these options use a custom field to track the number of times an issue fix has been rejected, and both use a post-function on the transition that is triggered when a fix has been rejected.


Requirements

Workflow configuration

Consider the workflow shown in Figure 1, right. This workflow is based on the default IT Service Management workflow.

In this configuration, the Resolved status is categorized as Done, but it is an unconfirmed resolution. A workflow could be configured this way to differentiate between an issue that the support team considers fixed but reporting requirements make it necessary or preferable to track closed issues separately. Additionally, an automation could be configured to close Resolved issues (and only Resolved issues) after several days of inactivity. Lastly, it enables the Fix Rejected transition, which is an integral part of this Recipe!

Figure 1 - Workflow Configuration

 

1. Create a Transition Count custom field for “Rejected Count”

  1. Log into your Jira instance as an Administrator.

  2. Click on the Settings icon in the upper right corner.

  3. Select Apps.

  4. In the left-hand panel, click Jira Misc Custom Fields then click My custom fields.

  5. In the upper-right corner, click New custom field.

  6. In the window that opens, select Transition Count and click Next.

  7. Select the screens on which the new field should be included. Click Next.

  8. Configure the custom field:

    1. Transition From Status - Select Resolved.

    2. To Status - Select Reopened.

    3. Click Save.

Figure 2 - JMCF Custom Field

 

2. (Option 1) Create a custom field for “Escalation”

  1. Log into your Jira instance as an Administrator.

  2. Click on the Settings icon in the upper right corner.

  3. Select Issues.

  4. In the left-hand panel, click Custom fields.

  5. In the upper-right corner, click Create custom field.

  6. From the list of Standard fields, select the type for your scenario:

    1. Checkboxes - For a single Escalated/Not Escalated setup.

    2. Select List - For multiple, different Escalated states.

  7. Configure the field (Figure 3, right):

    1. Name - Enter “Escalated”.

    2. Description - (Optional) Enter a description.

    3. Options - Enter the needed options.

      1. For a Checkbox, create a single option suck as True and click Add.

      2. For a Select List, create any options needed and click Add.

  8. Click Create.

 

3. Open the workflow

 

 

4. Add a Set issue field(s) post-function to the “Fix Rejected” transition

  1. In your workflow, add a post-function to the Fix Rejected transition:

    1. When viewing the Workflow in Diagram view, select the Transition and click the Post Functions link. Click Add post function at the top of the list of existing post functions.

    2. When viewing the Workflow in Text view, click the name of the Transition then select the Post Functions tab. Click Add post function at the top of the list of existing post functions.

  2. Select Set issue fields (JMWE app) from the list and click Add.

  3. Configure the post-function as follows:

    1. Target issue(s) (Point 1, Figure 4, right) - Set to Current issue.

    2. Add field(s) (Point 2, Figure 4, right)- Select the field you’re using for escalation, e.g. Flagged, Priority, or the custom field you created in Step 2 above, Escalated.

    3. Options - Set as needed. For example, if using Flagged or a checkbox version of Escalated, set the option Set only if field is empty so that the post-function will only attempt to escalate an issue that isn’t already escalated.

    4. Value (Point 3, Figure 4, right) - Enter Trueif using checkboxes, or the value to select if using a Select List.

    5. Click Add (Point 4, Figure 4, right).

    6. Send notifications - Configure as needed.

    7. Conditional execution (Point 5, Figure 4, right)

      1. Check the box for Run this post-function only if a condition is verified.

      2. Enter the following in the code editor:
        {{ issue.fields["Rejected Count"] >= 3 }}

    8. Run as - It is recommended to leave this set to Addon user.

    9. Delayed execution - Configure as needed.

  4. Click Add.