Showing results for 
Search instead for 
Did you mean: 
Sign up Log in
It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

Change the state of Story to the lowest status of subtask

Hey community. 

I am wondering - is it possible to assign the 'lowest' (or the earliest) status of a subtask to the parent issue? 

Our workfflow is 'todo -> in progress -> in review -> in qa -> done'. Lets say we have:


- subtast1 - status 'in progress'

- subtask2 - status 'in review'

- subtask3 - staus 'in qa' 

I want the parent story to have status 'in progress' - same as subtask1. If subtask1 status is updated to 'in qa' - I want Story status to be updated to 'in review' (equals subtask2 status now). 

3 answers

2 votes
Mykenna Cepek Community Leader Oct 06, 2021

Yes, I've done this. It sounds simple, but it's actually rather tricky with Jira Automation. I'll try to summarize the approach that is working for us.

-  -  -

Rule A triggers on Create, Update, Transition and Move. It uses a Conditional right away to focus only on Story-level issues (so this rule ignores Epics and Subtasks). It then goes through a series of conditionals:

  • If Story.Status != LowestStatus AND some Subtasks have Status=LowestStatus THEN transition Story to LowestStatus
  • Same for NextLowestStatus
  • Repeat through HighestStatus

So "todo" would be your LowestStatus and "done" would be your HighestStatus, with 2 in between. See the "important notes" below for exiting the rule after a conditional has fired successfully.

Note that Rule A will "force" the Status of a Story to be correct, based on the Subtasks. This prevents users from updating a Story to be inconsistent. It can seem odd on a Jira board, though to move a Story and then have Automation move it back. Boards that use swimlanes by Story work best here, helping users to focus on moving their Subtasks.

-  -  -

Rule B uses the same trigger as Rule A, but the initial Conditional focuses on Subtasks (so this rule ignores Stories and Epics). It also uses a series of conditionals:

  • If Parent.Status != LowestStatus AND some sibling Subtasks have Status=LowestStatus THEN transition parent Story to LowestStatus
  • Same for NextLowestStatus
  • Repeat through HighestStatus

Again, see the "important notes" below for exiting the rule after a conditional has fired successfully.

-  -  -

A few additional important notes:

  • I use a variable called ContinueFlag which is initially set to 1 (meaning the rule should continue executing). If a conditional matches, I set that variable to 0. Then after that conditional and the next one, I test the ContinueFlag in a Condition. The rule only continues if it is 1. That makes the rule terminate after the first matching conditional.
  • I would recommend getting Rule B to work first, as it is easiest to test (perhaps in a separate project).
  • Once you have both rules working, you will need to "bootstrap" each project (or if you're really brave, lots of projects). To do that, copy Rule A and change the Trigger to a Scheduled Trigger, use a Cron Expression of "0 0 0 1 1 ? 2000" (to keep it from executing), and check "Run a JQL search and execute actions for each issue in the query". For that JQL use "IssueType not in (Epic, Sub-task) and StatusCategory != Done". This focuses on only Stories which are not Done. You can use the "Run rule" button to bypass any schedule.
  • This works well for Scrum teams/boards/project, but not so well for Kanban. This is because of how Jira handles the Backlog. Let me know if you want more details about the complexity that Kanban adds.
  • Consider creating a set of manual "unit tests" that you can walk through and confirm proper operation. You'll likely make adjustments and enhancements to these (complex!) rules over time. And it always helps to be able to confirm that they are still working as expected. I documented those test steps and expected results in a Confluence page for my fellow Jira Admins.
  • If your rules evolve to be more complex, you might find a need to use the "Re-fetch issue data" Action, or the "Sub-tasks present" Conditional, to ensure proper behavior.
2 votes

Hi @anastasiia_levdyk 

You need to create a branch rule and use "Type of related issues" as parent along with few conditions I believe you can achieve this.

Something like this.


I have explained this here if you want to get more details.

I hope it helps and gives you some direction.


Hi @anastasiia_levdyk 

I believe the solutions suggested by both @Mykenna Cepek and @Ravi Sagar _Sparxsys_ will help you, and...please remember to think of edge-cases when testing your rule. 

For example, what if someone accidentally moves a subtask and then moves it back quickly to its original status.  Both moves would be seen by automation as events...however...the automation engine may "decide" not to trigger the rule again as it could detect this as a looping problem.  Think of this and other scenarios when you test the rule.

Thanks, and kind regards,

Suggest an answer

Log in or Sign up to answer
Community showcase
Published in Jira

Do you use Jira Cloud with Microsoft Teams?

Hi, Jira users! Do you use Jira alongside Microsoft Teams? We want to hear how you’ve used the power of Jira Cloud and Microsoft Teams (via the Jira Cloud for Microsoft Teams app) to achieve a team...

68 views 0 3
Read article

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you