Sub-task assignment automation based on prior assignee

[Chad Wege]

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:

Original 

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

Additional 

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?

[Bill Sheboy]

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,
Bill

[Mark Segall]

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
• BRANCH (JQL)
  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}}
• BRANCH (JQL)
  We'll clean up the label we just added
  • labels IN (masterIssue)
  • Edit Issue (Remove Label)

[Bill Sheboy]

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,
Bill

[Mark Segall]

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