Lookup issues in email and avoid duplicate

[Deleted user]

Hello I hope you are doing well, I'm having an issue with one of our customer, when their issue is modified the system send an email modifying the object and not the content of the email so I have several duplicate on my side. 

I tried the lookup automation rules but I would like a lookup with only the first couple words of the summary and not the whole things.

Exemple : 

Ticket #24135 has been re-opened.

Ticket #24135 status has changed to in progress

Ticket #24135 has been closed.

They are all about the same issue on our customer side but, our system create one ticket for each of them because the subject (summary) is not the same.

I would like to have a rule which look up only the 5 digits after the Ticket# to link them together and avoid duplicates.

Thank you in advance !

Help ! :P 

[Sachin Dhamale · Accepted solution]

@[deleted],

Welcome to the Community,

If this email are going through automation rule then need to make changes in the automation rule in the body section.

[Deleted user]

Thank you, I do know that but I'm wondering how with the lookup variables can I only look up a part of the text in the object for the summary and not the whole sentence.

[Stefan Salzl]

Hi @[deleted] ,

The following link describes several actions/functions regarding how to work with/manipulate strings from smart values:

https://support.atlassian.com/cloud-automation/docs/jira-smart-values-text-fields/

Best
Stefan

[Deleted user]

Thank you for the link, I did have a look at it, but how can I use the Lookup action in an automation to see if there is any other issue with the same start (first left 12 charac) as the one that trigerred the event ? 

[Bill Sheboy · Accepted solution]

Hi @[deleted] -- Welcome to the Atlassian Community!

For a question like this, please consider posting images of your rule and the audit log details.  That may provide more context for the community to offer suggestions.  Thanks!

Until then...I cannot discern if you are creating the new issues from an email handler or from an automation rule.  If it is from an automation rule, please take a look at the left() or match() functions to help extract what you need from the summary field: https://support.atlassian.com/cloud-automation/docs/jira-smart-values-text-fields/

Kind regards,
Bill

[Deleted user]

Thank you for the fast answer ! Sorry here the image of the rule (well my ''try'' as a rule ahah) : 

[Bill Sheboy]

Thanks for that information.

For your use case of wanting to link issues, the Lookup Issues is probably not what you need.  Instead you probably want to branch with JQL to match the issues for the linking.

Before changing your rule further, would you please clarify what is creating the issues that is triggering this rule: an email handler, another automation rule, or something else?  Knowing that will help to suggest improvements to try.

[Deleted user]

Wow you are the best.

The issues is coming from an email handler. It goes a little bit like this : 

-­ Receive email from customer

- An issue is created because the subject of the email is different (Even if it's the same Ticket, the fact that the status change is included in my customer email subject, Jira create a new issue.)

- Lookup in Jira if there is already an issue summary that contains the ''beginning'' of the summary (Here the value is Ticket #24135).

- If it already exist, transition the new issue to '' in progress'' and link it as ''duplicate'' to the already existing issue.

I hope it makes sense.

[Stefan Salzl]

@[deleted] 

Just wanted to point out this awesome description of your use case. This exactly describes the route of an event step by step and makes it completly traceable and understandable for other users/answerers. Love it 🙌🏼

[Bill Sheboy]

Hi, Sabrina.

Based on your description please consider the following:

1. What you describe seems like you are re-implementing service desk functions using email and newly created Jira issues.  Please consider investigating if Jira Service Manager would be a better approach.
2. Rather than relying on the summary, I recommend adding a custom field to specifically store the Ticket #.  This will make any future operations for related issues easier.
3. Once you identify the related issues in Jira for this ticket, you note transitioning the issue to "in progress".  If you do that, won't multiple Jira issues be in progress for the same Ticket # and lead to confusion?  An alternative would be to extract any new information from the email (in the new Jira issue description field), add that as a comment to the parent ticket, and then close/mark duplicate the new Jira issue.

Okay, assuming you still want everything you described, you could try this:

• trigger: issue created
• action: re-fetch issue (This can help prevent problems with the Issue Created trigger firing faster than the data being available for use.)
• condition: test for your noted reporter
• condition: test for the summary starting with "Ticket #"
• branch: on JQL to find matching issues for the ticket with summary ~ "{{triggerIssue.summary.left(14)}}"
  • action: link to the trigger issue
  • action: transition to the desired status
• action: edit to set the assignee for the trigger issue

Thanks,
Bill

[Deleted user]

Wow, you are wonderful, I did try the other way before you mentionned it with the custom field, the only thing I do not know how to write is the find matching issue with the same custom field. Thank you so much for all that context.

Let me know for the custom field and the last point for the comment is a wonderful idea as well.

[Deleted user]

I'm trying to find a way to make a ''match'' between the custom field of the triggerissue and all the issues in the JQL query :( Sorry if I don't get everything.

[Bill Sheboy]

It appears you only have a single rather than double-curly brackets for you smart value in the JQL.  Try adding that to see how it helps.

[Deleted user]

Oh it seems to works, now I only need to extract the description and add it as a comment to the new ''parent.issue''. And find the smartvalue to identify that.

[Bill Sheboy]

I believe the default email handler puts the information in the email body into {{issue.description}} so you may use that with the action to comment on an issue in the rule.

[Deleted user]

For some reason, the search does not find any issues even if the both customfield have the same information in them...

[Bill Sheboy]

Did you update the JQL as noted earlier as that image still appears to be missing the double-curly brackets around the smart value?

"Customer Ticket" ~ "{{triggerIssue.Customer Ticket}}"