Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Link duplicate tickets via automation rule

Lee Rourke July 19, 2023

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.

1 answer

0 votes
Trudy Claspill
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
July 19, 2023

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 July 20, 2023

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
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
July 20, 2023

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 July 21, 2023

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
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
July 21, 2023

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 July 21, 2023

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

Trudy Claspill
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
July 21, 2023

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 July 24, 2023

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

Trudy Claspill
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
July 24, 2023

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

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

Lee Rourke July 25, 2023

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

Trudy Claspill
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
July 25, 2023

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

Lee Rourke July 25, 2023

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
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
July 25, 2023

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.

Suggest an answer

Log in or Sign up to answer
TAGS
AUG Leaders

Atlassian Community Events