Are you in the loop? Keep up with the latest by making sure you're subscribed to Community Announcements. Just click Watch and select Articles.

Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


Using If-else logic to update status of a parent based on specific sub-tasks in status Ready


My Goal:

I want our devs and testers to use only the sub-tasks to update the status of their work. I.e. each Story has specific sub-tasks created for each person - backend, frontend, and QA - each with a corresponding [BE], [FE] and [QA] placed in the summary of the sub-tasks. Sometimes it could be multiple people of the same type working on the Story and sometimes it's just a combination of [BE] + [QA] or [FE] + [QA]. Every Story has to have an assigned QA in order to test.

How I think it will work:

I want the status of the Story to update only when the statuses of all the BE and FE sub-tasks are Ready.

I've been trying to use the If-else approach which seems the most comprehensive one.

My test:

I have a Story with each one of the sub-tasks - one of BE, FE and QA. So first I switch the status of the BE task to Ready (1), then switch the status of the FE task to Ready (2) and I expect the Status of the Story to switch to Dev Completed. There is already a workflow link from In development to that status.


This is my automation

if block.pngelse block.png



I get very weird errors and the actions are not performed.
here is the result from (1) - which seems to not do anything (And that's OK, as I don't expect anything to be changed), but the error is kind of weird. 

(1) run whe BE is moved to Ready.png


I expect that when (2) is run then the story will be moved to state Ready.

(2) run when the FE is moved to Ready.png

It says that the issue did not match the condition when in reality it is matching! Here is what the "i" icon is relating to. 

The thing that fails.png


The issue:

There is a Task with BE in the summary which is in the state Ready (I did this in (1)), but Audit shows that The conditions don't match and therefore the Story status does not change to Dev Completed.

Can someone shed some light on this? Thank you for taking the time.

Kind regards,


2 answers

1 accepted

I managed to fix this after trying a few more variants. 

What worked for this case is change the SQL rule condition : "Some match specified JQL". I had selected "All match specified JQL" - which meant it was expecting all sub-tasks to be with that summary name. I still get the weird error, but now the rule works as expected for the current scenarios!

Thanks to anyone who took the time to read through.

0 votes
Bill Sheboy
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
Oct 03, 2023

Hi Artur Balyan @ Immedis 

First, some tips...

When posting an automation question for a longer rule, please try using a screen capture or browser addon so the entire rule is in one image.  That will help ensure the context is shown relative to the audit log.  (Posting multiple images makes it more difficult to follow.)

Next, your solution is using the Summary field for multiple purposes, and that is often problematic and brittle.  A simple typo or edit can lead to mismatches.  Instead consider using an explicit indicator for your work-item types of BE, FE, and QA, such as a multiple-selection custom field or labels, independent of the summary field.

Next, I have not seen consistent results when using the related-issues, rule condition with JQL...particularly with the CONTAINS ~ operator, which is known to have defects all by itself.  I recommend removing all of those.  Instead try a single, lookup issues action to gather the issues (i.e., subtasks) and then use list filtering and advanced compare conditions to test.


Back to your question...

What you do not show in your scenario testing is what were the status and summary values of the other issues when you exercised your cases #1, 2, and 3.  As a result it can be difficult to diagnose what is happening, or to even compare to the audit logs shown.

My suggestions are...

  • Experiment with this rule in a test project, and not in your team's "production" Jira project
  • Map out your test cases, simplest first, along with your expected results
  • Create your test data's issues for the scenarios in a spreadsheet, allowing you to rapidly import and get to known starting conditions, repeatedly as needed
  • As your test on the parent issue's status is common to all paths, pull that earlier in the rule to one single, condition test
  • As your test on the trigger issue's status is common to all paths, pull that earlier in the rule to one single, condition test
  • Build this incrementally: add logic to support one test case, get that working, and repeat until done

Kind regards,

Hello Bill,

Thank you for taking the time to look through my problem.

I was trying to get the entire page with the "GoFullPage" plug-in, but it didn't catch the entire logic. So apologies for making this hard to read. 

I've tested extensively and didn't have any issues with other rules pertaining to the ~ operator and the related-issues block. There is very little room for error when using them because the Tasks are created with a manual trigger. When using a simpler solution I can get the status to switch, however, with more than one dev-type task (i.e. FE and BE) I can't get it to work. That's why I updated the logic to an if-else solution.


"What you do not show in your scenario testing is what were the status and summary values of the other issues when you exercised your cases #1, 2, and 3.  As a result it can be difficult to diagnose what is happening, or to even compare to the audit logs shown."

The Summary for the Tasks doesn't change, ever. The previous status of the FE and BE tasks is For Review. 

I've been following all the things you suggested until I reached that blocker. I was hoping to get feedback on the type of error (or the lack of error) that I am getting. IMO the simplest approach is the best one. So what remains is to try a different approach - like with the lookup action you suggested.

Kind regards,


Like Bill Sheboy likes this

Suggest an answer

Log in or Sign up to answer
AUG Leaders

Atlassian Community Events