Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

Sub-task assignment automation based on prior assignee

Chad Wege I'm New Here Sep 18, 2022

Our stories can have subsequent sub-tasks based on needed refinement, and I want to locate the assignee of the prior related sub-task to make them the assignee of the additional new sub-task.  This is what the scenario would look like under the story:


  1. Sub-task A.1 - assignee_1
  2. Sub-task B.1 - assignee_1
  3. Sub-task C.1 - assignee_2
  4. Sub-task D.1 - assignee_1


  1. Sub-task B.2 
  2. Sub-task C.2 
  3. Sub-task D.2 


I want to find the assignee from the original sub-task based on a value in the summary field, and use that to assign the corresponding additional sub-task.  Is there a way to get to that in Jira automation?

2 answers

Hi @Chad Wege -- Welcome to the Atlassian Community!

Short answer: maybe

Longer answer...with a lot of caveats:

If your related subtasks have summaries in a consistent format as you described, and you can write a JQL statement to find them, you could use a Lookup Issues action to get at the correct one.  Using an ORDER BY statement on the JQL for the lookup should help you select the correct one, making it always the last one returned.

For example: 

  • trigger: issue created
  • action: re-fetch
  • condition: is a sub-task
  • condition: assignee is empty (I am assuming you don't want to overwrite this if set when the issue was created.)
  • action: lookup issues with JQL to get at the correct sibling (same parent and related summary) AND not the same as the trigger issue
  • advanced compare condition: check to confirm the lookup results are not empty, checking that {{lookupIssues.size|0}} does not equal 0
  • action: edit issue to set the assignee to something like {{lookupIssues.last.assignee}}

Kind regards,

0 votes

Hi @Chad Wege and welcome to the community!

** Edited based upon @Bill Sheboy's response ** (Thank you Bill)

You could try something like this:

  • TRIGGER: Issue Created
  • CONDITION: (Advanced)
    Make sure the current sub-task is not a #1 sub-task
    • {{issue.summary.right(1)}}
    • does not equal
    • 1
    We need to branch into the parent issue and iterate through its sub-tasks 
    • parent = {{issue.parent}}
    • CONDITION (Advanced)
      Is the current issue summary the same as the trigger (evaluating against the example you provided (e.g. A.1, B.2, etc.)?
      • {{issue.summary.right(3).left(1)}}
      • Equals
      • {{triggerIssue.summary.right(3).left(1)}}
    • CONDITION (Advanced)
      Is the current issue the #1?
      • {{issue.summary.right(1)}}
      • Equals
      • 1
    • ACTION: Edit Issue (Add Label)
      We'll add a label here so that we can identify the master sub-task later.
      • masterIssue
  • ACTION: Lookup Issues
    • labels IN (masterIssue)
  • ACTION: Edit Issue (Assignee)
    • {{lookupIssues.Assignee}}
    We'll clean up the label we just added
    • labels IN (masterIssue)
    • Edit Issue (Remove Label)

Hi @Mark Segall 

Have you tried that technique before with a branch and created variable, shadowing?

My understanding is that branches with one-and-only-one issue (e.g. branch on Parent) get run-inline and so variable shadowing works.  But, for all other branches which could process multiple issues (e.g. JQL, related issues, etc.) they are run asynchronously and in parallel...leading to the variable being created and disposed of with each loop pass.  Thus it is a different variable than the one in the main flow.

Thanks, and kind regards,

Mark Segall Community Leader Sep 19, 2022

Good call out @Bill Sheboy - I just made an update to use a label instead.

Like Bill Sheboy likes this

Suggest an answer

Log in or Sign up to answer
Site Admin

Atlassian Community Events