You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
Next: Root
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
The Atlassian Community can help you and your team get more value out of Atlassian products and practices.
Hello everyone.
Following an issue creation, a few sub-tasks will be generated through an automation.
I need to establish status dependencies between a group of sub-tasks (f.e. Sequence 1) and a second group of sub-tasks (f.e. Sequence 2).
A user should be able to change the first status (To Do) of sub-tasks belonging to Sequence 2 just in case all of the sub-tasks belonging to Sequence 1 are Done.
I tried out a few solutions (including Worflow condition settings, automation exc.) with no positive results.
Do you have any suggestion?
Hello @Cristian Iorio,
Welcome to Atlassian Community!
Thank you for sharing the details.
Currently, it’s possible to block the transition of the parent issue when sub-tasks are still open, but not to block the transition of a sub-task depending on another one.
We can try to find a workaround here, so I would like to know more details about your use case.
You mentioned that there are groups of sub-tasks, what field are you using to differentiate both groups?
Is there any other solution that you tried like an add-on, for example?
Kind regards,
Angélica
Good evening, Angélica.
First, I would like to thank you for the kind support.
Actually, there are no explicit differences between the two sub-task categories.
With my teammates, we thought about implementing a 'support' field, to be used as a boolean, to define whether or not an issue can advance through different statuses. This solution, however, seemed to us to be intricated because we would have to act massively on a certain issue type (or, even more profoundly, create a new issue type for sub-tasks of the second category).
Do you have any suggestion about this?
Thanks for your attention.
Kind regards,
Cristian.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hello Cristian,
Thank you for the details.
We found an option that may help you and it’s necessary to use workflow conditions and automation.
In this case, it will be necessary to use automation to create the sub-tasks as you already do, but then create the group of sub-tasks based on transitions.
For example: When the issue is created, automation creates 3 sub-tasks. Then, to transition the parent ticket to the next status, all 3 sub-tasks must be done.
Then, when the ticket is transitioned, from To Do to In Progress, automation creates the other group of sub-tasks, and so on, to transition to In Progress to Closed, the sub-tasks must be Done.
Here is the test I made on my site.
On Project settings > Workflows, I edited the workflow that is linked to the issue type “Service Requests”. Then, I added a condition on the “In progress” transition.
The condition is called “Sub-Task Blocking Condition”. When adding this condition, on the next screen it’s necessary to select the status that the sub-task must be in order to be able to transition the parent.
Add the conditions to all necessary transitions and then click on “Publish draft” and save a copy of the workflow.
Now, it’s time to create the automation rules.
On Project settings > Automation > Automation, in my case here, the first rule will create sub-tasks when the ticket is created.
Then I created a second rule to create another sub-task when the ticket is transitioned from “Waiting for support” to “In progress”.
The results:
I created a ticket with the issue type “Service request” and 3 sub-tasks were created and we can see that it’s not possible to transition the parent issue to “In progress”:
Once the 3 sub-tasks were closed, the transition appeared:
After transitioning, the new sub-task was created:
This is a simple example of what can be done. Since it’s not possible to have groups of sub-tasks or block to transition sub-tasks based on another one, maybe would be a good solution to create sub-tasks based on the status of the main ticket, so if the “group” of sub-tasks are done, transition the main ticket and the new group of sub-tasks are created and the agents can work on that and they will only be able to move to the new status if the sub-tasks are closed.
Hope this helps!
If there is anything else we can do to help or if you have any questions regarding this matter, please let us know.
Kind regards,
Angélica
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.