Automation for 3 Strike Rule

Platform Notice: Cloud and Data Center - This article applies equally to both cloud and data center platforms.

Support for Server* products ended on February 15th 2024. If you are running a Server product, you can visit the Atlassian Server end of support announcement to review your migration options.

*Except Fisheye and Crucible

Summary

To create an automation for a 3-strike rule for tickets in Jira Service Management (JSM). Here's a breakdown of how this automation works and how to set it up:

Here's an example for each rule (We have considered "user creation" as one of the example issue type):

Automation Workflow
  1. Condition Check:
    • If issue type is 'user creation' and status is 'Waiting for customer'
  2. Strike 1:
    • 'Strike1' label is manually added by the Assignee
  3. Strike 2 (24 hours after Strike 1):
    • Condition: 24 hours after 'Strike1'
    • Action: Change Label to 'Strike2'
    • Action: Add Comment (2nd reminder comment)
  4. Strike 3 (24 hours after Strike 2):
    • Condition: 24 hours after 'Strike2'
    • Action: Change Label to 'Strike3'
    • Action: Add Comment (3rd reminder comment)
  5. Close Ticket (24 hours after Strike 3):
    • Condition: 24 hours after 'Strike3'
    • Action: Change Ticket Status to 'Closed'

First important point to consider here is to ensure that the automation system has the ability to schedule actions after a certain period. Here are the high level steps you can consider while creating an automation for aforementioned scenario:

Establish three new SLA goals: First Strike, Second Strike, and Third Strike, each with specific timeframes (First Strike: 24h, Second Strike: 48h, Third Strike: 72h). Configure the start condition as 'Entered Status: Waiting for Customer' and the stop condition as 'Comment: by Customer' for all three goals.

Next, implement three automation rules triggered by 'Scheduled' events using CRON expression. Utilize JQL (Jira Query Language for SLA's) to filter tickets based on SLA functions breached() and elapsed(). 

Detailed Steps for Each Strike Level

First Strike 

  • Presumably, the first strike involves adding the strike1 label to the ticket manually/via an automation if required.

Second Strike

  1. Trigger: Looks for issues labeled strike1 of type "user creation".
  2. Conditions:
    • Checks if the issue type is "user creation".
    • Verifies that the "First Strike" condition is breached (this might involve a custom field or label indicating a breach).
    • Ensures the labels do not already include Strike2 or Strike3.
  3. Actions:
    • Adds the Strike2 label to the issue.
    • Adds a comment "Second Strike" to the issue.

Third Strike

  1. Trigger: As above, but the rule specifically targets issues for the next level.
  2. Conditions:
    • Same as for the second strike, but also checks if "Second Strike" condition is breached.
    • Ensures the label Strike3 is not already present.
  3. Actions:
    • Adds the Strike3 label to the issue.
    • Adds a comment "Third Strike" to the issue.

Closing the Ticket After Third Strike

  1. Conditions:
    • Checks if the issue type is "user creation".
    • Ensures "First Strike", "Second Strike", and "Third Strike" conditions are all breached.
  2. Actions:
    • Adds a comment "Close" to the issue.
    • Transitions the issue to the "Closed" status.

These automation rules will trigger based on the specified SLA breaches, allowing you to take appropriate actions according to the defined SLA goals and conditions. Make sure to test the rules in a controlled environment before deploying them to ensure their accuracy and effectiveness.




Last modified on Jan 22, 2025

Was this helpful?

Yes
No
Provide feedback about this article
Powered by Confluence and Scroll Viewport.