How do I automatically trigger a status change on a parent issue based on the status of its children's statuses when a child's status is updated?

[andreas]

We are trying to automate our workflow. Here is what we would like to do:

We want to change the status of a parent issue (a story) when the status of one of its children changes. For example, suppose I have a story on the backlog that has 5 children that are also on the backlog. As soon as one of those children transitions from the backlog to an "in progress" state, I'd like to update the status of the story to have the status of "in progress" as well. The story would then stay in a status of "in progress" until its last child not yet in the state of "done" moves into a state of "done". At that time the story would be moved to a status of "done". We'd like to do this in an automated way so we never have to actually change the statuses of our stories.

Is this possible with your plugin? If we we'd love to know how to accomplish this. I can see how I would auto transition all subtasks from a change on the story, but not the other way around like we need it. There are lots of people trying to do the same thing online and there is really not a simple way to do it other than scripting it yourself. I am hoping Automation for JIRA can make this a bit easier.

[andreas · Accepted solution]

You can certainly do this with Automation for JIRA.  The rule is a little complex, but here's an example:

So lets break this down:

• First we execute this rule whenever an issue is being transitioned
• Next we check using a compare condition that the issue is a 'Sub-task'. We could have also used a JQL condition, but compare is a little faster to execute
• The we branch of for the parent using the 'related issues' action
  • We now check with a 'Related issues condition' that some sub-tasks are "In Progress"
  • We also check with a compare condition that the parent issue is not currently "In Progress"
  • If those are true, then we transition the parent issue to "In Progress"
• We have another branch point for the parent using the 'related issues' action
  • We check this time if all sub-tasks are "Done" using the 'Related issues condition'
  • If that's true, then we transition the parent to "Done"

The 2 'related issues' condition inside the two branch points, basically make sure the two branches are mutually exclusive and only one will ever execute.  Hope this makes sense!

[Sebastián Delmastro]

@andreasLove to hear if it is possible to make this on a set of those some sub-tasks and not all of them.

[Sebastián Delmastro]

Also @andreas what is the "Parent" condition? Works only for Subtask?

Any other "Parent" relation on Jira? 

[andreas]

Hi Sebastian,

Yeah so you could definitely restrict this further using the JQL condition and/or related issues condition to only run this rule when certain types of sub-tasks are transitioned.

The 'Parent' condition is actually an our 'Branch / Related issues' action.  It's a way to fork rule execution for related issues of the trigger issue.

There's an number of different options available to find related issues:

• Current issue
• Sub-tasks
• Stories (or other issues in Epic)
• Linked issues
• All created issues
• Most recently created issue
• JQL
• Epic (parent)
• Parent

(these are all in relation to the trigger issue)

So in other words, you can find the 'Linked issues' of a trigger issue, or you could find the Epic of the trigger issue etc.

Hope that helps!

Cheers,
Andreas

[Sebastián Delmastro]

Thanks @andreas.

You know what the "parent" option for related issues stands for?

[Sebastián Delmastro]

@andreas can´t make it work to transition Epic status based on Epic's linked issues status.

Any help is much appreciated.

 

[Sebastián Delmastro]

@andreas any news on my question above?

Epics I want to transition are on "Operation" projects only.

Linked issues can be of any type (bug, task, story, incidents and subtasks) and from different projects "Web Crawling" and "Application" with same workflows statuses.

I have Global rule config and all are on create screen already.

I tried with this other rule not on an Epic but on any Task, Story, Incident or Bug to transition from one status to another depending on his linked issues statuses, but is not working.

I branch out for elseif conditions the "For Current Issue" to apply on different status for his linked issues.  

Thanks

[Ola Garpendal]

Andreas, how do you implement the same solution in the Cloud version of Jira?

[Steve Comenzo]

Interested as well...

[Mark van Leeuwen]

@andreasSame for our company. If you could tell us how to implement this workflow on Jira Cloud it would really help us a lot.

[Herbert Krippner]

Would be interested as well

[Sebastián Delmastro]

@Herbert Krippner  @Mark van Leeuwen  

I work on a cloud version and this works fine for me:

We have a parent project called "Operation" and have several software factory related projects (Web, Data, Crawling, App) that transition the parent status issue based on their status issue.

(1) Rule must be global

If issue matches JQL transitioned is in any other project than the parent project "Operation" and is not an Epic (we use them on App, Web Crawling, Data, and others) then:

For Linked Issue (Types: can be "blocked", "is blocked by", "causes" relationships):

If: Issue matches JQL condition takes out the parent project and the "status" of the parent issue is going to be transitioned: 

Based on some of the statuses of the related issues:

(for example, we change the parent status to "In Progress" if some related software factory issues transition to "QA", "Code Review", "In Progress", etc)

[Aravind Koushik Gobburu]

Hi @andreas , I am trying a rule in jira for which all sub tasks must be closed so that story can be closed.If at all any sub tasks are not closed the story cannot be closed. I tried the rule which is as follows.

Unfortunately the desired results were not shown. Can you tell me where did i do a mistake. Thanks in advance!

[Mateusz Przybyłek]

Make a good use of it.

In current version of cloud we made it like below. For every transitions we have a copy of it

[Mateusz Przybyłek]

And we made this flow for almost every status in project

[Chris Chomicki]

And how to set up a rule that if subtask is transitioned to next column (X) than it checks if columns on the left are empty  and if yes than it gives a parent status X?

I would really appreciate answer :-)

[Ashlee Toney]

@andreas - I tried this, but it does not work on the Jira Cloud version. Please advise.

[s_vanleeuwen1]

Is it possible to automatically set assignee that had status ''in progress'' when ticket reached status ''closed''. In this case the assignee is not standard a person, but rather the person that picked up the ticket.

Does Jira support a rule when closed set assignee to assignee who had status ''in progress''?

Basically I want to have an overview of tickets done by assignee. Or maybe there is a better practise to do so then I am all ears! Due to the fact that certain statusses are automatically assigned to a person in my workflow (e.j. QA is assigned to QA-er), the last person in this workflow gets the ticket on its name when status is closed and I need to have the name of the person that actually fixed the issue, name of the person assigned when status was ''in progress'' ( so not the tester for example). 

[Katherine Lisman]

I just used this help page to change the status of a story when one or all of the sub-tasks status changes. This might help with any parent/child relationship, such as Epics and stories/tasks.  

https://www.atlassian.com/software/jira/automation-template-library/rules#/rule/140671

Not sure about the board part...you might check this page out for popular automation templates:

https://www.atlassian.com/software/jira/automation-template-library/most-popular

[Paula Machado]

Is this also applied to Epics that are Done Status and I need to triger them to be set on another board?

[jeff.kehler]

I have a rule working to do this fine in Cloud, albeit a simpler approach as I only want to watch a single transition.

My teams tends to grab their subtask and get to work, forgetting to update that parent "Story" level status, which is all that really matters to the PMs (and myself) in most cases.

In simple English...

WHEN a subtask is transitioned from 'STATUS A' to 'STATUS B'

AND the PARENT is in 'STATUS A'

THEN TRANSITION PARENT to 'STATUS B'

The problem I am having is that the assignee of my parent story is being set to AUTOMATION FOR JIRA when this rule runs which was not part of my automation rule at all. 

Is this an automatic function or something?

Any input is appreciated. This is only my second rule using automation for Jira Cloud.

[Nico Hunink]

Hi jeff_kehler, 

Thank you!! 😃

I hope you already have found the answer, but otherwise I have 2 options for you (in Jira Cloud):

1. When you open your Rule in the list of rules you have in your automation space, you will see the 'Rule details'. In the bottom, you will find 'Actor*'. Here you can choose (at least at the moment I am writing this) for 'User who triggered the event'. 
   
   
2. Before I found option 1, I thought: it has to be possible that the user who triggered the event, should also be the assignee of the parent issue. So I added another action at the very end, so after the transition of the parent: 'Edit issue' > 'Assignee' as field of the issue and lastly > 'User who triggered the event'. 
   
   Not that difficult in logic, but you have to find it and understand if first (I know I struggled to find my way around this in the next gen-project 😉 )
   
   

I really wanted to help you in this (if still applicable/necessary) because your screenshot helped me to set up my own rule. So thank you again for that! 🎉 👍

And although I am writing this at 5 AM in the morning (couldn't sleep), I am still genuinely grateful that you shared your ideas! Seems like a nice #hashtag to me '#genuinelygrateful' 😃

Kind regards and have a great day today! 

[Vehbi Katrancı]

Thank you it worked for me.

[Shrilacxmi Bose]

Hi Sebastián Delmastro,

I have setup a rule,but its not getting executed successfully in Transition state.

[Ashlee Toney]

We are now using the JMWE plugin, way better for things like this and their support is amazing!

[Sebastián Delmastro]

Totally disagree with you @Ashlee Toney never seen better user-non-programmer-friendly interface with automation and their support never fails. Keep your comments like this somewhere else.

Thanks  

[Ashlee Toney]

I was simply stating my experience with Automation for Jira and JMWE. Please keep this professional. We are all allowed to provide our opinions and support in the Community to help one another choose the right option that works for our companies.

[Sebastián Delmastro]

In my opinion, as you say you should help others providing feedback, experience and how it worked for you from one tool to another rather than a 1 line comment adding 0 value.  ;)

[Ishara Gunarathna]

I am trying to change the status of the Jira Service Desk (linked issue) when the status is changing in Jira Software. Searched the web, but couldn't find any reference.

[Sebastián Delmastro]

Automation for Jira works great on that.

https://docs.automationforjira.com/issues/branching.html#related-issues-condition

We use it on daily basis.

[Caleb Ruth]

 I am trying to so something a little different. I have a project that when it needs to be escalated it creates a new ticket in another project and automatically links the two. the issue i am hitting is, that i want the linked ticket (the child) when moved, to update the status of the original ticket ( parent). 

I may be missing something, but i cannot get it to work. @andreas any help would be great!!!! 

[Dan Marcantel]

does not work