Automation Create Duplicate Sub-Tasks

[Lawrence Elkins]

My organization is having an issue with Jira Cloud automations tied specifically to checklists.  Here is the background on the use case:

We have a Software Project where each issue ticket of type "Feature" will be created with a checklist template pre-loaded onto it.  This checklist has about 20 different boxes, and each box refers to a different work task that we might want to execute for the Feature ticket (think tasks like "Gap Analysis", "User Flow Diagram", "UX Wireframes", etc.).  When the ticket owner clicks a checkbox, we want a sub-task to automatically be created on the Feature ticket that corresponds to the checkbox selected.  We only want a single sub-task to exist for any given task type (i.e., we do not want it to be possible to create 2 or more "Gap Analysis" sub-tasks via the checklist automation -- this is the main issue we are experiencing).

The automation is defined as follows (using the sub-task "Gap Analysis" as an example):

• When: Value changes for `Checklist Text` // Whenever a box is checked, the text will update
• If: all match
  • Checklist Text contains [x] Gap Analysis // The "Gap Analysis" checkbox is checked
  • No Sub-tasks match Summary ~ "Gap Analysis" // There are currently no "Gap Analysis" Sub-tasks
  • Then: create 1 sub-task with Summary = "Gap Analysis" // Create the "Gap Analysis Sub-task

Now when a user performs the checklist workflow slowly, this works as expected.  But if a user rapidly clicks a checkbox on and off multiple times in quick succession, the automation will create a bunch of duplicate Sub-tasks for "Gap Analysis"!  This pretty obviously seems like a race condition for the asynchronous calls fired off via the automation.  I tried to add a new Re-fetch issue data component right at the top of the rule execution to make successive executions re-pull the issue data before executing, but this did not work.  It seems that the core issue is the delay between the automation executing and the Sub-task actually being created on the Feature ticket.  Looking around old forum posts and Atlassian's internal public Jira, it does not seem like there is a way to insert artificial delay into an automation's execution (which would probably solve this issue).

This seems busted on Atlassian's end.  What are we supposed to do here?  Or is this simply impossible given the current state of Jira Cloud?

[Gracjan Wesołowski _HeroCoders_]

Hi @Lawrence Elkins 

my name is Gracjan, and I'm a Customer Success Expert at HeroCoders, the team behind the Issue Checklist for Jira Pro app, that you are using.

I have reviewed your use case and came up with another idea:

In your automation instead of creating a subtask, add a label, and create another automation that would create a subtask whenever the new label is added. The first automation will not add a label twice, because that's how Jira works, and your second automation will create a new subtask just once. Please find the automation below:

1. Trigger - Field value changed - Checklist Text.

2. Issue field condition, pick Checklist Text, and check if it contains [x] Gap Analysis

Second Issue field condition, pick the Labels field and check if it contains a label named Gap_analysis

3. Edit Issue action - Pick the Labels field, and add there Gap_analysis.

This automation will simply add a label whenever we have a change in Checklist Text, based on 2 conditions.

Second automation:

1. Trigger - Whenever any change is made to Labels

2. We need to add re-fetch data here to slow the trigger.

3. Issue field condition - Pick the field labels, and check if it contain the Gap_analysis label.

4. Create a sub-task!

This way we will avoid creating several sub-tasks. Let me know if that works for you :)

Cheers!

Gracjan

[Bill Sheboy]

Hi @Gracjan Wesołowski _HeroCoders_ 

Thanks for this additional idea, and here are some questions...

Wouldn't your rule #2 (Gap Analysis subtask creation) need to enable the "Allow Rule Trigger" option, as your rule #1 is performing the action that will trigger rule #2?

I have observed some rule (and REST API) actions lead to edit events even when there are no data changes for a field.  Have you tested your rules to confirm rule #2 does not trigger multiple times due to the race-track condition?

And in rule #1 you are showing the case for "Gap Analysis", and it seems like Lawrence as multiple values.  Were you suggesting having one rule for the different cases (using if/else conditions) or having separate "rule #1" types for each value? 

Kind regards,
Bill

[Lawrence Elkins]

Interesting proposition Gracjan,

Are you sure that including the "re-fetch issue data" component is enough to impose synchronicity on the rule execution?  I would have thought that adding that to my initial automation would have been enough to resolve my race condition issues, but it was not.  Your solution sounds promising (and I'm certainly willing to try), but are you positive it avoids the race condition?

I suppose it entirely depends on how the automation updates the label on the Feature ticket (and if there is a delay between checking the rule and applying the label).  I'm assuming that my original issue's root cause was that there is a fundamental delay between executing an automation, creating a sub-task, and having the Feature ticket be aware of the fact that it has a new sub-task (relevant because the automation hinges on the Feature ticket recognizing it already has the specified sub-task created).  If there is no delay in an automation applying a label to a ticket, your solution should work.  Otherwise, it's impossible to guarantee that it will work in all cases.

This is definitely not a problem with your guys' addon -- it seems to be an issue fundamental to Jira Cloud's implementation (which Atlassian seems unwilling to fix or even investigate).  Related ticket: https://jira.atlassian.com/browse/AUTO-238 -- I love how the "current workaround" is to stack re-fetch issue data actions as if this is a logical and acceptable workaround in an expensive enterprise product.

Anyway, I'll test your approach Gracjan and see if it could work for us.

[Gracjan Wesołowski _HeroCoders_]

That's true, you will have to Check the allow rule trigger option in the second automation I forgot to mention that, thank you @Bill Sheboy

Mine automation works with labels, where it is not possible to add the same label twice. Even though you still check/uncheck the Gap item, the label will be added once, and the automation will trigger once. I've tested this case scenario where I checked, and unchecked Gap item several times, and the issue creates automation triggered just once.

Mine automation just added an additional step with labels to avoid the problem with multiple triggers for the second automation.

Let me know @Lawrence Elkins if it works for you.

Cheers!

Gracjan

[Bill Sheboy]

Hi @Lawrence Elkins -- Welcome to the Atlassian Community!

Rules seem by-design to trigger fast (which is great), and so even without marketplace addons they may get race-track errors (which is not so great).  One example is the Issue Created trigger, which can fire so fast the issue data is not available for use in the rule!

Would you clarify your scenario a bit?  That may help the community offer ideas.

Which, if any, of these match your scenario...

1. A person creates a new "Feature", which has a pre-loaded checklist template.  However, they do not select the checklist items at the time the Feature is created for some reason.  Instead they set the checklist options later, and changing them one-by-one triggers an automation rule for each change, to create sub-tasks for the Feature (with no duplicates, based upon Summary value).
2. A person creates a new "Feature", which has a pre-loaded checklist template.  At the time they create the Feature, they select the desired checklist values.  At a later time, they might change the checklist values.  In either case, an automation rule runs which creates sub-tasks for the Feature (with no duplicates, based upon Summary value).

I am guessing it is case #1 and that you are using a marketplace addon for checklists.  Both of these (#1 and 2) can lead to race-track errors in rules, although #2 will have significantly fewer.

Which checklist addon are you using?  Have you investigated if the checklist items can be selected during the initial create of the issue?

Kind regards,
Bill

[Lawrence Elkins]

Hey Bill,

Thanks for your response!  I'm not sure I understand the distinction between scenario #1 and #2, but users do not select the checklist items during the Feature ticket creation -- they select them after the Feature ticket has been created (at the same stage where they might be writing a description for the feature, adding labels, linking other tickets, etc.).  The automation fires every single time a checkbox in the list is selected / deselected, which can be at any time during the ticket's lifecycle.  

Good call on checking the addon -- tbh, wasn't even aware that this was not a native Jira feature.  I think the addon we are using is called "Issue Checklist for Jira. Pro" made by HeroCoders (here's the marketplace link).  Looks like there is some Jira Automation documentation they have, so I'll take a peek and update this thread with what I find.

[Bill Sheboy]

Thanks for confirming that, Lawrence.

Follow-up question: how soon after the Feature is created and the checkbox fields are selected does your team need the sub-tasks to be available: immediately, within a short time, the next day, etc.?

As long as it is not immediately, you may be able to solve this race-track condition by using a scheduled trigger rule instead.  For example, a rule could check once per hour (or day...) for Features which do not yet have their sub-tasks created, and then create them.  That would reduce the chance of collisions with people still doing edits.  As a backup, a manually triggered rule could have the same behavior so it could be run immediately to create them.

What do you think?

[Lawrence Elkins]

That sounds like a promising approach -- having a manual step to create the sub-tasks from the checklist would be a last resort, but having this on a recurring schedule could work -- thanks for the suggestion, I think we will try it!

[Bill Sheboy]

Hi @Lawrence Elkins 

Just following up to check if this answered your question.  If so, please consider marking this one as "answered".  That will help others with a similar need find solutions faster.  If not, please let the community know what help you need with the rule changes.

Thanks!