Link duplicate tickets via automation rule

[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.

[mararn1618 _secretbakery_io_]

Hi @Lee Rourke,

I believe Trudy's answer is pretty good regarding matching tickets with exactly the same summary (or partially the same).

Since I am the author of a deduplication plugin**, I just want to add this plugin here, since it can do semantical matching of tickets. That means:

• The whole ticket content is considered (not just the summary)
• The ticket content doesn't need to be the same.
  (example "I cannot log into my laptop, after the recent update" matches "After the update was done, the login to my computer doesn't work")

Maybe that helps. Cheers, Markus

** Duplicate AI on the Marketplace 

[Trudy Claspill]

Hello @Lee Rourke 

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?

[Lee Rourke]

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.

[Trudy Claspill]

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? 

[Lee Rourke]

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.

[Trudy Claspill]

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?

[Lee Rourke]

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

[Trudy Claspill]

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.

[Lee Rourke]

So i have got this far, but cant seem to do the final assignee part? 

[Trudy Claspill]

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:

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

[Lee Rourke]

Will it still be under issues if i dont have this when the customer fills it out?

[Trudy Claspill]

i don't understand your question. Will what thing still be under "issues"?

[Lee Rourke]

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?

[Trudy Claspill]

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.