Validator or Conditional Closing - Workflow Restrictions & Automations

[marianna_taborda]

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!

[Maciej Dudziak _Forgappify_ · Accepted solution]

Hi @marianna_taborda 

I think the best approach would be to use a Jira Expression-based Workflow Validator, which will consistently prevent the transition when conditions are not met. There are several options available on the Atlassian marketplace.

Our team at Forgappify has developed a specific validator for linked issues, available within the Workflow Building Blocks for Jira app. This Linked Issues Validator could be applied in situations like yours without requiring deep knowledge of Jira expressions. However, it currently allows filtering based only on issue type, whereas you mentioned needing to filter by label as well.

What makes this tool particularly helpful is its Jira expression preview panel, which assists with learning and constructing Jira expressions. Using this feature, you could create the expression you need, incorporate the label check, and then apply it within our Jira Expression Validator to meet your specific requirements.

I would appreciate it if you could give it a try.

Cheers

[marianna_taborda]

Thank you so much! I think this would be a perfect solution, but I'm afraid the company won't allow for the use of third party apps. I will explore, nonetheless. 

Another question: it would not be possible to have a buffer on a status transition to allow selected rules to execute, would it?

[Maciej Dudziak _Forgappify_]

It is written in Forge, maybe company will allow it.
I don't think it there is another solution, and slowing down the transition is definitely not possible.

[marianna_taborda]

Hey @Maciej Dudziak _Forgappify_ !

I'm checking this solution out but I can't seem to find the answer to some questions, if you could help me, please:

• Can I use this extension on a team-managed workflow, on a service project? 

[Maciej Dudziak _Forgappify_]

Hi @marianna_taborda

Unfortunately, Jira workflow editor for team-managed projects don't yet support third-party validators; I am afraid, right now, only use in company-managed projects is possible.