nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Automation-Link a tickets Linked tickets

Chris Edris

I have 3 projects that can be linked together: Support (TCST), Dev, OPS.

The normal flow is:

1. Support opens a dev ticket and links it to the support ticket.

2. Dev fixes the bug and creates an OPS ticket for deploy

3. Dev links the OPS ticket to the Dev ticket.

When Dev links that OPS ticket, I want to link the same OPS ticket back to the support ticket that's already linked to the Dev ticket.

This is what I've tried, but it's not right.

Screenshot 2026-03-11 at 16.00.30.png

Accepted answers

Himanshu Tiwary_go407r

Hi @Chris Edris , I think the main issue is that your rule is a bit too broad once it starts branching through linked tickets. The trigger itself makes sense, but when you use “For linked work items,” Jira will go through all linked issues on the Dev ticket, and at that point it does not clearly distinguish between the Support ticket and the OPS/Deploy ticket. That is why the rule can end up acting on the wrong linked issue or not giving you the result you want.

For your flow, the rule really needs to identify the two linked tickets separately. In your example, the Support ticket is linked to the Dev ticket first, then later the OPS/Deploy ticket is linked to that same Dev ticket. What you actually want the automation to do at that moment is detect that the Dev ticket already has a linked Support ticket, then take the newly linked OPS/Deploy ticket and create the same link between OPS and Support. So the logic is less about looping through every linked issue, and more about finding the correct ticket from each side and then linking those two together.

A better approach is usually to trigger the rule when an issue link is created, then add conditions so it only continues when the current issue is the Dev ticket and the linked issues match the projects or issue types you expect. From there, you can use a lookup or smart values to identify which linked ticket is the Support one and which is the OPS one, and then create the missing link directly between those two. That tends to work much more reliably than a generic branch over all linked issues.

If this helped, I’d really appreciate an upvote.

All comments

Himanshu Tiwary_go407r

If this helped, I’d really appreciate an upvote.

mr john_8cmnbt

I’ve faced a similar scenario before. One way to handle it is using automation rules (if your platform supports it, e.g., Jira Automation). You can set it up so that when a Dev ticket links an OPS ticket, the rule automatically finds the parent Support ticket linked to that Dev ticket and links the same OPS ticket to it. This keeps the chain intact without manual linking. Has anyone else implemented something like this?

Chris Edris

Hi, Himanshu.

I really appreciate your help. I tried making the changes you suggested as I was able. I'm still pretty new at this, and I appreciate your patience.

I am now getting the ops ticket # returned as {{issue.key}} and both the Support and the OPS ticket getting returned for {{destinationIssue.issuelinks}}

I tried to write some JQL to capture all of the {{destinationIssue.issuelinks}} that belonged to support, but it isn't working. Is there a better way to iterate through the {{destinationIssue.issuelinks}} to capture just the support links? I'm assuming I can then link the {{issue.key}} to each support link.

Screenshot 2026-03-12 at 10.48.35.png

Himanshu Tiwary_go407r

Hi @Chris Edris

What you’re trying to do makes sense, but the part that’s fighting you is {{destinationIssue.issueLinks}} because it returns a collection, and JQL is not great at cleanly filtering that inside the rule.

A simpler and more reliable approach is to let automation do the walking for you instead of trying to force it through JQL.

Since your Destination work item is already the OPS ticket, you can first store that key in a variable, then branch from that OPS issue into its linked work items. Inside that branch, check whether the linked issue belongs to the Support project (or use issue type if that’s more reliable in your setup). Once the rule lands on the Support ticket, you can create the missing link directly between that Support issue and the original trigger issue.