JWT

JWT-RULE-001

Block backward transition from In Progress to Open

The transition from 'Work in Progress' to 'Open' occurs for 182 items (17.43%) and is always rework. This indicates a process failure where issues are moved backward from an active state to an intake queue. Blocking this path enforces a forward-moving process and reduces rework loops, as seen in Variant 5, which increases average duration by nearly 170 hours compared to the happy path.

Trigger

Work in Progress → Open

Conditions

·JQL: issuetype = 'Work Type = Incident'

Actions

·validator: Restrict transition execution

Script JWT JSON

[
  {
    "type": "validator",
    "name": "Restrict transition execution",
    "config": {
      "condition": "false",
      "errorMessage": "An Incident in 'Work in Progress' cannot be moved back to 'Open'. Please move it to 'Pending' if it is blocked, or cancel it if it is no longer valid."
    }
  }
]

JWT-RULE-002

Ensure 'Close Code' is set before closing an Incident

The 'Close Code' field is critical for understanding resolution outcomes, with 92% of incidents having a 'Solved' code. The 'Completed -> Closed' transition is the most frequent in the process (93.49% of items). Making 'Close Code' mandatory on this transition ensures 100% data completeness for reporting and trend analysis.

Trigger

Completed → Closed, Work in Progress → Closed

Conditions

·JQL: issuetype = 'Work Type = Incident'

Actions

·validator: Field Required Validator

Script JWT JSON

[
  {
    "type": "validator",
    "name": "Field Required Validator",
    "config": {
      "field": "Close Code",
      "errorMessage": "Please provide a 'Close Code' before closing the Incident."
    }
  }
]

JWT-RULE-003

Scheduled: Auto-close stale Incidents in 'Pending' status

Incidents can become stale in the 'Pending' status, often awaiting user feedback (as evidenced by the 'No feedback from user' Close Code in sample data). This inflates the average duration (256 hours). A scheduled rule to automatically close these incidents after a defined period of inactivity (e.g., 5 days) will reduce manual follow-up and shorten the overall lifecycle.

Conditions

·JQL: issuetype = 'Work Type = Incident' AND status = Pending

Actions

·scheduled_rule: Daily check for stale Pending incidents

Script JWT JSON

[
  {
    "type": "scheduled_rule",
    "name": "Daily check for stale Pending incidents",
    "config": {
      "cron_expression": "0 0 1 * * ?",
      "jql_scope": "issuetype = 'Work Type = Incident' AND status = Pending AND updated <= '-5d'",
      "actions": [
        {
          "type": "post_function",
          "name": "Set field value",
          "config": {
            "field": "Close Code",
            "value": "No feedback from user"
          }
        },
        {
          "type": "post_function",
          "name": "Add a comment",
          "config": {
            "comment": "This Incident has been automatically closed due to inactivity for more than 5 days."
          }
        },
        {
          "type": "post_function",
          "name": "Transition issue",
          "config": {
            "transition": "Close"
          }
        }
      ]
    }
  }
]

JWT-RULE-004

Require justification for reopening a Completed Incident

Reopening completed work ('Completed -> Work in Progress' transition, 2.68% of items) is a form of rework that disrupts team focus. Requiring a comment during this transition forces the user to provide a clear justification, capturing valuable context for why the initial resolution failed and discouraging unnecessary reopens.

Trigger

Completed → Work in Progress

Conditions

·JQL: issuetype = 'Work Type = Incident'

Actions

·validator: Comment Required Validator

Script JWT JSON

[
  {
    "type": "validator",
    "name": "Comment Required Validator",
    "config": {
      "errorMessage": "Please provide a comment explaining why this Incident is being reopened."
    }
  }
]

JWT-RULE-005

Auto-assign Incidents based on Subcategory

Manual assignment is a bottleneck that delays resolution. The data shows clear ownership patterns (e.g., 'VPN' subcategory issues are handled by 'Network and Firewall'). This post-function on creation will use conditional logic to automatically set the 'Assignment Group' based on the 'Subcategory', reducing time in queue and speeding up time-to-resolution.

Trigger

* → Open

Conditions

·JQL: issuetype = 'Work Type = Incident'

Actions

·post_function: Set field value using an expression

Script JWT JSON

[
  {
    "type": "post_function",
    "name": "Set field value using an expression",
    "config": {
      "field": "Assignment Group",
      "expression": "def subcategory = issue.get('Subcategory')?.value;\nswitch (subcategory) {\n  case 'VPN':\n  case 'WAN Connectivity':\n  case 'Webfilter':\n    return 'Network and Firewall';\n  case 'Software Installation':\n  case 'Access':\n  case 'Patching':\n    return 'Application Services';\n  case 'Mobile Device':\n  case 'Tablet':\n    return 'Mobile / Cell Phones';\n  default:\n    return issue.get('Assignment Group');\n}"
    }
  }
]

JWT-RULE-006

Require a reason when moving an Incident to 'Pending'

The 'Work in Progress' <-> 'Pending' loop is the most significant source of rework and delay, appearing in numerous top variants (e.g., Variant 4, 6, 8). To combat this, a validator will require the user to select a reason from a 'Pending Reason' custom field. This provides clarity on the blocker and establishes clear exit criteria, reducing ambiguity and time spent in a waiting state.

Trigger

Work in Progress → Pending, Open → Pending

Conditions

·JQL: issuetype = 'Work Type = Incident'

Actions

·validator: Field Required Validator

Script JWT JSON

[
  {
    "type": "validator",
    "name": "Field Required Validator",
    "config": {
      "field": "Pending Reason",
      "errorMessage": "Please select a 'Pending Reason' to explain why this Incident is being put on hold."
    }
  }
]