Jira Automation - Link Issues across multiple projects depending on Custom Field Value

[Debs Olivares]

Hi Everyone,

We're trying to set-up a Global automation that will compare the value of a custom field found on the trigger issue and on all of the issues queried in the below filter. If the value is the same on any of the issues within the query and the trigger issue, a link will be created between the two tickets.

The "For: JQL" section is:

project = "ABC" and type= "IssueType" and status="Open" and "customField" is NOT EMPTY

The issue with this automation is that it sort of works. For some reason, it'll also affect new tickets that don't even have that custom field. 

[Bill Sheboy]

Hi @Debs Olivares -- Welcome to the Atlassian Community!

Would you please show the audit log details with the rule execution?  Looking at that, and an example issue with this symptom may help.

What is the type of that custom field: text, single select, multiple select, etc.?

Also...if you add that condition directly to your JQL the rule condition will not be needed:

project = "ABC"
 AND issueType = ???
 AND status="Open"
 AND "Internal Study Name" IS NOT EMPTY
 AND "Internal Study Name" = "{{triggerIssue.Internal Study Name}}"

Please note I put ??? in for the issuetype, as it is unclear what value you wanted to use: Story, Task, Bug, Epic, the same as the trigger issue, etc.  Please confirm that also.

Please note well: smart values are name, spacing, and case-sensitive, and often do not match the field's display name on the issue views.  Please use this how-to article to confirm you have the correct smart value for your field, "Internal Study Name"

https://support.atlassian.com/cloud-automation/docs/find-the-smart-value-for-a-field/

Kind regards,
Bill

[Debs Olivares]

Hi Bill, thanks! 

Yeah no probs, it's quite the big screenshot sorry 

All those STU tickets from the JQL query. the custom field in question is a "Select List (multiple choices)". and this is what I get from the link you provided: "customfield_10388": "Internal Study Name", 

[Bill Sheboy]

Did you expect to get that many issues back?

If you manually test that JQL outside of the rule, with an example value for the field, does it only return the issues you expected?

Finally, do you mean that custom field is single select or multiple select?

[Debs Olivares]

Sorry for the delay! But yes it does look right since it should be over 200 tickets. And I'm actually just now realising it's a multiple select field. Does that change how the automation would behave (vs. having a single select).

[Bill Sheboy]

Rules have a limit of 100 issues for a trigger, branch, lookup, etc. in a single batch, and so this may not work for your scenario due to the issue created trigger.

What problem are you trying to solve by linking together that many issues: what is the "why"?  Knowing that may reveal other solution approaches.

[Debs Olivares]

Someone requested that for all issues where the Internal Study Name had a certain value, it would be linked to the STU ticket. 

For example, there's a ticket created in the STU project with the issue type Study Start-Up, this ticket has the custom field "Internal Study Name" set to the name of a study. There are multiple projects across Jira using that "Internal Study name" custom field as well. What they want is to have an automation set up so that when a ticket in any project is created where the Internal Study Name field has a value, it'll link that ticket to the matching STU Study Start-Up ticket. They've been doing it manually previously.

I'm sorry, I hope my explanation makes sense. I can clarify it more

[Bill Sheboy]

Thanks for that information, and I do not believe a rule triggered on Issue Created can solve this when there are potentially more than 100 issues involved. 

Do more than 100 issues have the same value for the specific Internal Study Name" when a new issue is created?

In practice, how are that many links actually used: reporting, progress tracking, etc.?

I suggest meeting with your Jira site admin to describe this scenario, as perhaps I am missing the "big picture" and a better solution is available.