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; } } }

Getting the linked issues count using jira automation

Gayathri B_jfn2ec

Hi,

I am trying to write an automation where

1. The trigger is "Issue linked" and it is automatic trigger not manual

2. The automation should search the linked issues and scan through the linked issues severity field.

3. Based on the Severity : High / medium - it should update in High = X and Medium = Y field.

4. Most importantly it should increment the count, everytime an issue gets linked to the parent ticket.

I have tried a way using branching rules and lookup issues condition - but it takes a long time to return. What can we do here?

Accepted answers

All comments

Harrison Ponce

Hi @Gayathri B ! This sounds like a very interesting use-case :-)

Would you mind sharing a screenshot of what you have set up so far in your automation? I'm trying to understand where the count of linked issues is being stored in your case.

Trudy P Claspill

Hello @Gayathri B

You said:

everytime an issue gets linked to the parent ticket.

With generic issue linking there is not a parent/child relationship recognized by Jira.

What link types are you using? And how do you know which issue is considered the parent in those link relationships?

Gayathri B_jfn2ec

In our use case, we will be using "is blocked by" link for linking all the defects that get raised during the testing of the parent ticket. That being said, only the defects will be linked under this link by our teams. So it is only up to us to get the count of all the linked issues separated by the priority and then taking this count for our further reporting mechanisms.

The issue trigger is "issue link deleted", this is the exact same logic for "issue linked" as well. So I just want to get the logic below that to be checked.

The branching mentioned below extends to two more severity types. So on the whole there are 3 branches. Everytime the automation gets triggered, it goes through all branches and takes upto 6-7 secs to run which is slowing the process.

Logic for getting the "urgent issues count" is {{lookupIssues.size}}

I want to optimise this by options to reduce branching logic or alternate methods

Thanks!

Screenshot 2025-02-06 at 1.22.47 PM.png

Gayathri B_jfn2ec

yes you got that in my reply above! @Harri

Trudy P Claspill

You said that the rule is taking a long time to return. Does it consistently take longer than the rule that is triggered by Issue Linked that otherwise references the same destination issue?

How many issues are you retrieving in the Lookup Issues actions?

Gayathri B_jfn2ec

Hey Trudy,

My comparison was between a manual and an automated trigger.
A manual trigger will run only when it is called out, and since it is manual the team will not be calling it again and again and would only trigger it when they are done, or midway sort of.

But when I try to automate this, where in everytime when a new defect is linked, the rule has to automatically run, logistically taking 6-7 secs for every new defect getting linked does not look like a good rule built.

So I want to refine it. It could be shrinking 3 branches to 1, or using some other conditions that ensures the rule is automated and still running in an optimised manner

during my testing, I used 4 -5 issues linked

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

automation

smart-value

lookup