How can I create an automation to link child issues of an epic to a linked target issue

[Robin Schubert]

Hello together,

I have a little bit difficult requirement. I have an epic and I will manually link this epic with an issue „XYZ“. My epic is linked with child issues. I would like to automatically link my issue „XYZ“ with all child issues of the epic. Is it possible with automation rules? Or does anyone has another idea?

Alternative:

I have an issue „ABC“ that is linked with other issues over the issue link type „relates“. Now I create another issue „XYZ“ and link it with my issue „ABC“ with the link type „fulfills“. I would now like to automatically link my new issue „XYZ“ with all linked issues of issue „ABC“ that are linked with issue „ABC“ over the link type „relates“. Does anyone has an idea for that?

[Bill Sheboy · Accepted solution]

Hi @Robin Schubert 

Both of your scenarios sound possible to implement with automation rules.  The part I do not understand is how you are identifying the "target" item to link.  Would you please clarify your question?

For example:

• Trigger: manually triggered (from the epic)
• Condition: issue type is Epic
• Branch: for the linked issues
  • Action: link issue to the specific issue desired (e.g. XYZ-123)

So the question: is XYZ-123 hard-coded, a field in the Epic, or what?

The first two cases can be handled with automation, the what unknown case is, well...undefined.

If you flip the trigger, and start from XYZ-123, I don't see how you would find the Epic unless it was already associated to the issue.

Best regards,

Bill

[Robin Schubert]

Hello @Bill Sheboy

thank you for your answer! I would manually link an epic (from project A) with an issue (in project B). And this linking should create additional links between the epics childs and my issue.

Is this possible to realize?

Best regards,

Robin

[Bill Sheboy]

Hi @Robin Schubert 

That sounds possible, and I recommend first writing down some example cases of the linking to help you create rules.

And here are some example rules in the library to give you ideas:

https://www.atlassian.com/software/jira/automation-template-library#/label/all/1453

Once you create your rule, if you run into problems please your rule back here so the community can give you ideas.  Thanks!

Of note: as this rule spans different projects, it will need to be a global-level rather than a project-level rule.  This means you need to monitor the execution usage limits.  Please see here for more details:

https://support.atlassian.com/jira-core-cloud/docs/what-are-service-limits/

[Paul Benati]

[Jira Software - Cloud all with Next Gen projects]

I have an automation that, based on an issue type, creates issues on other kanban boards.  For example, when someone creates a PROJECTS issue of issue type Bare Metal, an automation runs, resulting in three new issues on different kanban boards being created (i.e., EMON-3, ENET-14, & DCT-72).  Of course, these newly created issues are linked to the PROJECTS issue (i.e., PROJECTS-1) linked as...

PROJECTS-1 is linked to

• EMON-3
• ENET-14
• DCT-72

I'd like an automation that will link the children issues to each other.  Thus,

• EMON-3 linked to
  • ENET-14
  • DCT-72
• ENET-14 linked to
  • EMON-3
  • DCT-72
• DCT-72 linked to
  • EMON-3
  • ENET-14

Any ideas on how to make this happen?  I assume doing this in the same automation that creates the linked issues (i.e., EMON-3, ENET-14, & DCT-72) is the best place to do it, but maybe it's a separate automation that runs when each of these issues are themselves created?

[Bill Sheboy]

Hi @Paul Benati 

Your question seems related to, and different from, Robin's question.  I recommend creating a new question in the future to help the community find it faster.  Thanks!

The challenge with your use case is it probably needs nested branches to iterate over the created issues to do it in one rule, and that is not possible with the current automation capabilities.

Instead you may want to:

• Create an issue-created triggered rule in each project (EMON, ENET, and DCT)...
• That rule can iterate over the linked issues from PROJECT-1 based on JQL to link them...
• The challenge is how to find the PROJECT-1 issue to drive the JQL.  If that link is obvious (say, EMON-3 has a specific link type to PROJECT-1) it should be straightforward to do.

Best regards,

Bill

[Paul Benati]

Bill,

I've been able to retrieve the appropriate issues and they're stored in the {{lookupissues}} smart value, but how do I get them linked?  Would the Link Issues component work?

Thanks,

Paul

[Bill Sheboy]

Hi @Paul Benati   

I don't that structure will work because Link Issues is expecting on key, not a list.

• When you use a branch, you may process each issue, one by one
• When you use Lookup Issues, you process them as a set.  For example with a math operation or when you want to send one email with a list of issues.

You will probably want to change your branch to use JQL that satisfies all of your criteria, and then link.

[Paul Benati]

Bill,

I don't see a viable path as I'm starting from the child, as per your earlier recommendation.  Thus, I have to first branch to the Parent to find its linked issues.  Once I find them, I can't iterate on the looked-up issues and branch over them since nested branches aren't supported.

Do you have any other thoughts on how to solve this? 

Thanks,

Paul

[Bill Sheboy]

Hey Paul,

If we go back to your originally posted issue structure, this is a fairly specific use case for automation.  I believe you can do this with 4 global (multi-project) scope rules.  This assumes you always add the 3 issues.  (So, change the rules if that assumption changes.)

First rule in PROJECT:

• Trigger: the original parent issue is created in PROJECT
• Action: add the EMON issue, linking to the PROJECT one
• Action: add the ENET issue, linking to the PROJECT one
• Action: add the DCT issue, linking to the PROJECT one
• Action: re-fetch (this will reload the triggering PROJECT issue and its links)
• Branch: linked issues (of the triggering PROJECT issue)
  • Action: add a specific comment (or other change) to trigger sibling rules.

Sibling rules (one in each project: EMON, ENET, and DCT).  Each of these rules should enable the option Allow rule trigger in the details.  This allows the first rule to fire the sibling rule.

• Trigger: comment added matching your criteria (e.g. specific comment)
• Action: create variable, {{varParentKey}}, to get key of linked issue PROJECT
  • There are a few ways to get the parent key and you may need to experiment to make sure you get the right one, depending on how you linked them in the first rule.
    • {{issue.issuelinks.outwardIssue}}
    • {{issue.issuelinks.inwardIssue}}
    • Worst case, is to get the key using JQL in two steps: lookupIssues and then get the key with {{lookupIssue.key}}
• Branch: JQL on other issues linked to PROJECT issue
  • For example: issue IN linkedIssues({{varParentKey}})
  • Action: add link to trigger issue

What do you think?

Best regards,

Bill

[Paul Benati]

All,

Okay, I figured it out.  No branching required!

[Note: for testing purposes, I used a manual trigger.]

Steps (check out the attached for details)

1. Trigger = Issue created [Note:  this would be for one of the child issues.]
2. Use a Lookup issues command to find the parent of the issue
3. Create a variable to store the key of the parent (e.g., {{myParent}})
4. Use Lookup issues commands to find each possible sibling.  In this example, EMON-3, ENET-14, & DCT-72.
5. Use a match() to find each one
6. Use a Link issue command to link the child to each of its siblings

[Bill Sheboy]

Well done!

Please note, the reason I switched the sibling rules (EMON, ENET, DCT) to use a rule trigger other than Created Issue is there is no guarantee that all three issues will exist by the time you want to link to them.  So your second lookup issues call may find 0-3 issues, subject to the timing of rule execution/trigger capture in the Cloud.

Best regards,

Bill

[Paul Benati]

Bill,

Yes, I see your points and really appreciating the thinking and resulting guidance.  I believe this will work nicely.

Note:  I forgot about the re-fetch mechanism...definitely needed.

Thanks,

Paul

[Paul Benati]

Bill,

Any thoughts on how to prevent the same sibling from linking multiple times?  I'm doing a check prior to linking to see if the sibling is already linked, but I believe the asynchronous nature of the executions is tripping this effort up.

What if I added a re-fetch command after each "Link issue to" command as shown in the last image?

Note:  the two automatons below are triggered by Comments.  The second image shows the comment payload for the 2nd automation.

Thanks,

Paul

[Bill Sheboy]

Hi, Paul. 

With the potential for parallel rule execution you will not be able to solve the timing issue with the re-fetch in this case.  For example, the re-fetch might occur just a moment before it is needed to solve the duplication problem.

Four potential approaches to "solve" this are: 

• Don't solve it: ignore and accept potential duplicate links
• Create a chain of rules, such that each successive rule triggers the next.  This seems like a brittle solution to me.
• Add logic to remove extra links.  This is really complicated and may not work for your case.  (I did this for labels and components, but there weren't parallel running rules.)
• Pause, and re-think the problem you are solving.  For example, why is it important that the child issues are cross-linked when they have the parent to connect them?  Considering that answer may lead you to a different strategy.

Best regards,

Bill

[Paul Benati]

Bill,

Excellent insight, thanks.  I chose to pause and re-think the problem.  There are two goals:

1. quick access to the sibling cards
2. distribution of comments from sibling to the other siblings

This led me to add the sibling links into the Description of the parent and its children.  And then the distribution of comments was a quick regex parsing of the Description.

Thanks again for all your help Bill!

-- Paul

[Martin Cleaver]

Did you conclude how to solve this?

Also, on DC there is no "create variable", invalidating many solution options.

One approach I quite like is to create webhook endpoints and pass JSON structures around. This allows the functionality to be called from multiple places as if the rules were callable functions.

Finally, I cheat by calling SIL or ScriptRunner for "last mile" problems. Life is too short on DC.

[Walter Lamm]

@Paul Benati @Martin Cleaver @Bill Sheboy I too had the same problem of duplicate links while linking all child issues. This is how I solved it and it works like a charm: