Help needed - Multi-linking on issue creation

[Colin]

Good afternoon! I hope you're all having a great weekend!! I have an automation working to create two tasks for a single issue when a sprint is started. It's set to link each task to the trigger issue, which works fine. 

I need help figuring out how to link the created tasks to each other. It's not a deal breaker for what I'm trying to achieve, as the user can click on the story and then click on the other task if there are any details on it they may need, but in my head, with the power of automation, it should be possible! 

Ultimately, I'm attempting to add an issue for both backend and frontend developers and have them all linked to each other as 'relates to'. 

I guess it would go...

• Story 1 creates Task/Subtask 1 & 2 (Late last night, I wondered if it's better to use subtasks rather than tasks since they get pulled into the sprint and tasks end up in the backlog).
• Story 1 relates to created 1 & 2
• Created task/subtask 1 relates to story 1, and created task/subtask 2
• Created task/subtask 2 relates to story 1 and created task/subtask 1

As I understand it, I should only need to link one of the created tasks/subtasks to the other as it will display the link on both.

Below is what I have set up at the moment. I've read and tried a few different articles, but I have not managed to get it working yet. Any help is appreciated!!

[Ste Wright]

Hi @Colin 

Can I clarify...

• When the Sprint starts, is it only one issue which receives the new Tasks? Or could there be multiple?
• Is the aim to link Created Issue 1 to Created Issue 2, using linked issues?

Ste

[Colin]

Hi @Ste Wright 

I hope I'm on the right path here. Ultimately, I'm attempting to add an issue for both backend and frontend developers. 

• There could be multiple. When a sprint starts, it's any issue of the type story in that sprint; I've set it to add a label as well, which it checks for to avoid any duplicates for issues that carry over from one sprint to the next.
• And yes, I would like to link the created issues to each other. At the moment, I can link the story to each so the story shows both as linked, but each created only shows the story, but not the 'other' created.

I guess it would go...

• Story 1 creates Task/Subtask 1 & 2 (Late last night, I wondered if it's better to use subtasks rather than tasks since they get pulled into the sprint and tasks just end up in the backlog).
• Story 1 relates to created 1 & 2
• Created task/subtask 1 relates to story 1, and created task/subtask 2
• Created task/subtask 2 related to story 1 and created task/subtask 1

I'm just over-engineering it a bit; the user can easily find created issue 2 by clicking on the story link and accessing it from there. I just thought it would be a 'nice to have' if each created task/subtask were linked to each other and the story that created them.

[Bill Sheboy]

Hi @Colin 

The challenges to do this are: your rule is already using a branch, and I believe rules require adding the link as separate action after the issue create action.

As your rule is already using the Send Web Request action, you could add one more to add the links: https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-issue-links/#api-rest-api-3-issuelink-post

To reference the two previously created issues, I would use created variables rather than trusting that {{createdIssues}} (the plural smart value) will be correct for the branch.  To do that, after each issue create inside the branch, save the key {{createdIssue.key}} in a variable...then reference those variables in your REST API call to link the issues.

As an observation: have you checked the running time of your current rule?  With branched issue creation and REST API calls, I suspect this one is taking a long time when there are several issues in the sprint.

Kind regards,
Bill

[Colin]

Hi, @Bill Sheboy 

Thanks for the tips; I will look at that and report back!

Yeah, in my testing, about 30 issues or so take a little under a minute if I have to add them all. I had only added the calls as a delay due to some early version errors that I suspected were due to the timing of various parts happening. I've not checked recently if they are still needed; this is all just a PoC at the moment, so once I have it doing everything I need it to I'll start thinking about streamlining it a little