Link duplicate tickets via automation rule
Asked by Lee Rourke:

Hi,

Can you please advise what automation rule i would need to create to link duplicate open tickets from the same email (reporter) so the first ticket is the main one and the new duplicate is the secondary one.


Answers:
author: Trudy Claspill
body: Hello [@Lee Rourke](/t5/user/viewprofilepage/user-id/5272189)

Welcome to the Atlassian community.

Are you working with Jira Cloud or Jira Server/Data Center?

Besides the issues having the same reporter how do you know that they are duplicates? Couldn't one person submit two different requests via email?

comments: author: Lee Rourke
body: Yes they could, but we are seeing people submit duplicate requests.

I have an automation on where it is a round robin so it is allocated to my team fairly, but a member of the team was dealing with a customer already as they submitted duplicate tickets.

Is there anyway to run an automation that if there is a ticket out there with the same reporter it can link to the current ticket so that only one member of my team will action this.

Or if there is a way to assign the new ticket to the assigne that already has the ticket from the same reporter.

I am trying to avoid duplicated work.


author: Trudy Claspill
body: The work of linking tickets and assigning tickets can be done by Automation Rules.

The trick is you have to tell the rule how to determine that a ticket is a duplicate of an existing ticket.

If a given person can submit multiple tickets that are not duplicates, then saying that the new ticket has the same reporter as existing tickets is not an adequate criteria for identifying duplicates.

Can multiple agents be working on truly different tickets from the same reporter? If so then again you can't determine which of them to assign to the new ticket simply based on it being the same reporter.

Do the "duplicate" tickets have the same text in the summary field?

If you manually look at the tickets, what all are you examining that helps you determine the new ticket is a duplicate of an existing ticket?

Would it matter if the duplicate older ticket has already been closed?


author: Lee Rourke
body: Yes multiple agents can be working on different tickets from the same reporter, but recently we have just seen a customer raise multiple tickets with different summaries, so wanting to know how i can get round that please.


author: Trudy Claspill
body: If the summaries are different then how do you know the issues are duplicates?

If you have to read the content and make a judgement call that it really means the same thing as a different sentence, that is not something you can create a rule to replicate. You must be able to apply some codable logic to the comparison.

Is there some other field or content that will be the same between the tickets? Or could you assume that if a second ticket was created within a small amount of time after the first ticket then the are *likely*to be duplicates?


author: Lee Rourke
body: Ok if the summaries are the same can a rule be created at least that will be half the battle :)


author: Trudy Claspill
body: Yes, if the summaries are the same you could create a rule like this:

When issue is created

Lookup Issue

- use a JQL like this:

project = \<your project\> and Reporter= {{issue.reporter}} and Summary \~ "{{issue.summary}}" and issue != {{issue.key}}

Advanced Compare Condition

{{lookupIssues.size}} equals 1

Then take action against the newly created issue to set the Assignee to

{{lookupIssues.first.assignee.accountId}}

...and link it to the issue found.

Note that with this rule if the Summary within the new issue is contained in a larger Summary of another issue, that would also be picked up in the Lookup Issues action.

i.e.

Older issue summary: "My dog is brown and white"

New issue summary: "dog is brown"

The older issue would be considered a match to the new issue based on the summary.


author: Lee Rourke
body: So i have got this far, but cant seem to do the final assignee part? ![Capture30.JPG](https://community.atlassian.com/t5/image/serverpage/image-id/270691i897758B171C6A92B/image-size/large?v=v2&px=999 "Capture30.JPG")


author: Trudy Claspill
body: First, in the JQL for your Lookup Issue action remove the "\<" and "\>" characters surrounding your Project Key. I used those characters to indicate a variable you needed to replace. You want only the actual project key there, not those extra characters.

Regarding setting the Assignee, you don't want to use "User who triggered the event". The event that triggered the rule is "Issue created" and the user that triggers that event is the person that creates the issue - the reporter. You don't want the Assignee set to the reporter. You want it set to the Assignee in the issue that was returned by your Lookup Issue action.

You need to use a smart value for that, and I gave you that information here.
> Then take action against the newly created issue to set the Assignee to
>
> {{lookupIssues.first.assignee.accountId}}

**{{lookupIssues}}** is the object that contains the list of issues returned by the Lookup Issues action. **{{lookupIssues.first}}** instructs Jira to look at the first issue returned in that list. (Note that **first** is s a special option. That doesn't mean that **second, third, fourth,** etc. are also valid options.) **{{lookupIssues.first.assignee}}** tells Jira you want the value from the Assignee field of the first record in the results set. **{{lookupIssues.first.assignee.accountId}}** tells Jira you want the Account ID of the Assignee of the first record in the results set.

Setting User Picker fields using a smart value requires that you provide the Account ID. Using the built in options to "copy" (i.e. "User who triggered the event") get the Account ID themselves so you don't have to worry about it. But there is no built in function like that to copy the value out of the Lookup Issues results set.

To set the field to a smart value you first have to tell the rule that you want to use a smart value:

![Screen Shot 2023-07-24 at 9.56.02 AM.png](https://community.atlassian.com/t5/image/serverpage/image-id/270788i054A0C9866D71720/image-size/large?v=v2&px=999 "Screen Shot 2023-07-24 at 9.56.02 AM.png")

After you do that, then you can type in the smart value I provided, into the second field.


author: Lee Rourke
body: Will it still be under issues if i dont have this when the customer fills it out?![jira screen.JPG](https://community.atlassian.com/t5/image/serverpage/image-id/270917iDF920DA43F869CC2/image-size/large?v=v2&px=999 "jira screen.JPG")


author: Trudy Claspill
body: i don't understand your question. Will *what thing*still be under "issues"?


author: Lee Rourke
body: Just when you have the formula lookup issues, is that standard no matter how the jira looks to a customer, as it doesnt mention issue anywhere?


author: Trudy Claspill
body: I'm sorry, I'm still not quite grasping your question.

The Lookup Issues action uses JQL to retrieve issues, just like you would use in the issue search screen. You can incorporate smart values into the JQL to leverage information available within the rule where the action is used.

What you can use for the JQL in the Lookup Issues action may be impacted by the configuration of your Jira instance, similar to how the elements that can be used in the JQL on the issue search screen are impacted by the configuration of your Jira instance.