Description:
We’re experiencing challenges with automation timing in our Jira workflow, which affects ticket closure when Confluence issues are identified. Here’s a detailed breakdown of the workflow, the problems we’re facing, and our requirements for a solution.
Workflow Context:
1. Ticket Intake: Support teams raise tickets in Jira to request assistance, ask questions, or escalate issues.
2. Internal Analysis and Labelling: As we work on these tickets, we identify any:
- Knowledge Gaps with the support team.
- Documentation Issues with Confluence content.
3. Clone Creation for Confluence Issues: For Confluence issues, a clone is triggered in another service desk for the CF editors to review. This clone needs a description and considering the destination issue type, we use manual triggers and user inputs before escalation.
4. Closure Requirement: We want to ensure that any ticket with a Confluence issue cannot be closed without having a linked clone in the external service desk.
Problem Statement:
We need to automatically prevent ticket closure if a Confluence issue has been identified but the escalation clone has not yet been created. This is where our workflow encounters multiple challenges:
Automation Delay: We use an automation rule to apply labels to tickets based on issue type. This rule is slightly delayed, sometimes applying the label a split second after the closure attempt. By this time, the ticket is either already closed, or we receive an error because the label hasn’t yet been processed.
Conditional Restriction Needed: Not every ticket will involve a Confluence issue. Therefore, we only need to restrict closure when specific labels indicating a Confluence issue are applied. However, if there’s no Confluence issue, the ticket should close as usual.
Specific Issues we’re Facing:
1. Timing Misalignment: The automation is sometimes delayed, causing the closure restriction to be bypassed or resulting in errors.
2. Inconsistent Application: Due to the slight lag, tickets are occasionally closed prematurely, missing the Confluence label application and violating our workflow.
3. Catch-22 Situation: If we enforce a hard closure restriction, it disrupts standard ticket processing for cases where there’s no Confluence issue, causing unnecessary workflow bottlenecks. But without this restriction, we risk tickets closing without proper escalation when Confluence issues are flagged.
Desired Outcome:
We need a solution that can reliably:
Prevent closure when a Confluence-related label is applied, only if a linked clone for the CF service desk is not yet created.
Allow tickets to close as usual when no Confluence issue is identified (i.e., no specific label is applied).
Any guidance or recommendations on adjusting the automation’s timing or achieving conditional closure restrictions would be greatly appreciated.
Thank you in advance for your assistance!
