Create dependencies between subtasks under the same parent task

[Ellen Gruebbeling]

Hello all! 

I hope that this message finds you well! I have seen posts/questions with a similar request previously added, but nothing that has directly solved what we are attempting to accomplish. I also wanted to see if there were any additional/streamlined options based on more recent system updates or configurations. 

I am looking for an automation rule that creates dependencies between subtasks under the same parent Task issue. The dependency aspect relates to the dependency of the item being tracked generally, such that the assignee of subtask two should not start their work until the assignee of subtask one has completed their part and moved the subtask to Done status. However, the team wants all of the subtasks created at once prior to the start of work on subtask one, so that they have it one their dashboard as upcoming (while those who are assigned to a subtask other than subtask one are aware that they have work upcoming, but it is not ready for their contribution due to reliance on the prior subtask, which would allow for planning/scheduling purposes). Therefore, having an automation rule where each subtask is created separately, after the prior subtask has been moved to Done does not accomplish the goal of how the team would like to use this configuration (however they would like to have the ability to add subtasks at a later date if needed, with these subtasks working into the overall automation). 

For example -> the Task issue has five subtasks all created one day after the Task is created. The goal is that subtask two will move to "In Progress" status following subtask one moving to "Done" status. This will alert the assignee of subtask two to update them/make them aware that it is time for their work on the subtask two to begin and would also update the start date as the date the subtask moved to In Progress (based on the prior subtask moving to Done status) and the due date as the date of update to In Progress plus 7 days. Once the assignee of subtask two moves their subtask to Done status, the status of the third subtask would move to In Progress, and so on with subtask four and five. The only status that would trigger the status update on the next subtask would be Done (other statuses will be used to signify additional work is needed from the Task assignee, etc.). 

I have created a few different versions of automation rules that attempt to accomplish these updates, however, have thus far been unsuccessful. 

(Trigger) For instance, when subtask is moved to Done (trigger),

(Then) THEN lookup work items using either a sequence number (number custom field) or the issue key 

1. project = PROJECT_KEY AND parent = {{triggerIssue.parent.key}} AND "Sequence Number" = {{#=}}{{triggerIssue.parent.key}} + 1{{/}}

2. project = PROJECT_KEY AND parent = {{triggerIssue.parent.key}} AND Key  = {{#=}}{{triggerIssue.key.plus(1)}}

3. project = PROJECT_KEY AND Key  = {{#=}}{{triggerIssue.key.plus(1)}}

(Then) AND Transition the work item (next subtask) -> To Do

However, none of the above options have updated the next subtask - they either do not result in any update to any of the subtasks or they update the trigger subtask status only incorrectly (the subtask that should have moved and stayed in Done status). 

Ideally, we would like the ability to have the next subtask considered as the next subtask based on the order/listed on the Task, rather than based on the next occurring work type key, which would necessitate the subtasks be created in order and would potentially not permit the automation to apply to subtasks that needed to be added at a later date (or when a task in the same project was created while the initial subtask were being created, resulting in a missed or "skipped" key in the list of subtasks). However, how can the order be incorporated in the rule in this manner, especially as subtasks can be rearranged and reordered from the Task view (without manually updating)? The team would also like to reduce the need to manually update the dates/statuses as much as possible.

Any recommendations or guidance on a potential automation rule that would permit these actions would be greatly appreciated! Please let me know if you have any questions or if any additional information is needed. Thank you!

[Bill Sheboy · Accepted solution]

Hi @Ellen Gruebbeling 

Thanks for explaining your scenario and what you have tried thus far.  As a tip, for automation questions it helps to post an image of your actual rule and the audit log details to provide context.

From what you show, you are trying to increment the work item key values and that will not work.  The key looks something like ABC-123 and so it cannot be incremented.  And, using the numeric id value of each work item likely would not help as there can be gaps in the numbering.

Scenarios like what you describe can be solved by carefully adding the subtasks in your desired order and adding linking between the pairs, such as "depends on" or "is blocked by".  Then when the predecessor completes, rule branching can find the next one to work upon.

How are your subtasks created: manually, with an automation rule, import, or some combination of these?  The method of creation will help the community suggest how they can be linked.

Kind regards,
Bill

[Ellen Gruebbeling]

Hi Bill, 

Thank you for your response! The sub-tasks will likely be created either individually manually (creating each one separately) or through a combination of manually creating each individual one and then cloning the original to create the subsequent ones. 

Using the work key was one potential approach; however, if there is an alternative automation approach/rule that could be created to complete the updates needed, that would be great. The Sequence Number custom field was a different approach with a similar set-up, but does rely on identifying a way to set the Sequence number in an order that accommodates how the team will use the subtasks. 

Apologies regarding the lack of screenshots for the audit log and automation rule. Thank you for your assistance with this!

Thank you,

Ellen

[Bill Sheboy]

Thanks for the additional information, @Ellen Gruebbeling 

The primary thing with dependent work items is having something to connect them, as that allows walking the chain for checks, updates, etc.  And so the team needs to select one method and use that consistently.

If the team is manually creating the work items, they could add links at the same time.  That would likely be easier than using a sequence number, custom field as people would need to keep track of the next number when making updates.  Although once the connections are in place, a rule can be written to find and update the next dependent one.

Perhaps read this article from @Trudy Claspill discussing updating dependent work items when linking is used.  That will give you an idea of what is involved for that versus using the numeric field.

https://community.atlassian.com/forums/Jira-articles/Updating-dependent-task-s-dates-when-predecessor-task-date/ba-p/2816977

[Ellen Gruebbeling]

Thank you, Bill! I appreciate your assistance with this and for providing this information!