Avoid creating a new issue for a mail thread

[Sanskruti Khandelwal]

Hi,

For the email request type currently a new issue is generated for a mail in the same mail thread and we don't want that to happen. Is there any way in which a new issue is not generated for the thread? Or any automation which we can create for the same such that the issue is not assigned to anyone? If yes, Also if that issue for the mail thread is resolved can we reopen it again if we have a reply from customer?

For the same, we tried creating an automation using JQL condition but it doesn't work. The JQL condition used:

summary ~ "{{issue.summary}}" order by created DESC > 1

If the condition is true, keep the issue unassigned but even for the first mail on any mail thread, the issue still remains unassigned. 

Can we use such queries in automation, If not provide the JQL statement type which we can use in automation

Also, There is any way to not generate an issue for same mail thread?

[Jessica Jagpal]

I have a similar issue. On ticket creation I use automation to send the ticket to the reporter because in Customer Notifications I can't edit the display name it will show the agent's name which I don't want, but I can in Automation make the display name anything I like. However, when the reporter replies, it creates a new ticket when it should add the reply as a comment on the ticket. Is that by design? The From Address by default is noreply@automationforjira.com which is greyed out and I can't change. I add the Reply to email address as the address for the project. 

I know using customer notifications the reply from the customer will go back on the same ticket. 

So i'm stuck - use customer notifications but can't edit display name OR use Jira Automation, but every reply creates a new ticket, neither is ideal.... 

[Angélica Luz]

Hi @Jessica Jagpal,

Thank you for reaching out to Community!

For the comments to be added correctly to the ticket, as you mentioned, it’s necessary to use the customer notifications from the project, otherwise, it will create a new ticket. 

What can be done in this case, is to let the customer know that they can’t reply to that notification and if they need to add a comment, they must go to the portal. In case you don’t want to use an add-on, agents can create the ticket on their behalf and then, add that detail on the description or add a public comment with the reasons why the ticket was created on their behalf. 

• Receive requests from an email address

If you don’t mind using an add-on, the Email this issue has some features that may help you.

Kind regards,
Angélica

[Jessica Jagpal]

I figured out why it was creating a new ticket. Because I was using Jira Automation to send the notification on create issue, I manually set what the subject of the email should be and didn't include  {{issue.key}}. Once I added that value to the subject, replies went back into the ticket. 

Is there ANY way to force the display name to be the project name instead of the agent that caused the action if I want to use the built in customer notifications? 

Best,

Jess 

[Angélica Luz]

Thanks for sharing, Jessica.

When an agent creates a ticket on behalf of a customer, the notification will show the “From” using the agent’s full name and it’s not possible to change that. 

There is a feature request suggesting the implementation of this ability:

• Raising a request on behalf of the customer should generate a notification with the "From" from the project's name and not agent's name

Please, click on vote and watch to receive updates about the feature.

[Angélica Luz]

Hello @Sanskruti Khandelwal,

Welcome to Atlassian Community!

When a customer replies to a notification and a new ticket is created instead of adding the comment to the ticket, it means that the customer who is replying doesn’t have permission to comment on the ticket.

For example, a customer sends an email and creates the ticket IT-123, they will receive notifications when an agent adds a comment, then they forward the notification to their manager, and the manager replies to that notification. A new ticket IT-124 will be created because the customer (reporter) just forwarded the notification instead of adding the manager as a participant. 

What I’m saying is that, if who replies to a notification is not the reporter, participant, or a member of an organization which the ticket was shared, the reply to a notification will create a new ticket instead of adding a comment to the original one.

To prevent this issue from happening, the reporter must share the ticket with the people they need to be involved in the ticket, and also, they must be sure to reply to the notification using the exact same email address they used to create the ticket (if a customer uses a mail client with different inboxes it can happen that they use the incorrect email to answer the notification).

It’s possible to reopen a ticket if a customer adds a new comment, for that, it will be necessary to add a new transition to the workflow in order to allow that Closed goes back to the status Waiting for Support, for example. Then, create an automation that will reopen the ticket. For more details, please check the article below:

•  Reopen ticket with automation rule

Regarding the automation, would you like that the automation to unassign tickets that are a reply/duplicated of the original one?

If possible, share with us a screenshot of the automation rule so we can better understand and help you with this request.

Kind regards,
Angélica

[Sanskruti Khandelwal]

Hey Angélica,

Thanks for the reply.

Got your point about the permission to comment on the ticket. But for a ticket we have a person A on the request participants and when that person A replied on the mail, a new ticket was generated which according to you shouldn't have generated. Is there any other reason for this behavior?

And, Yes! For the automation part, we want the tickets to not generate at all for reply/duplicates. If incase the ticket is generated we want it to be unassigned and not present in the open tickets. Since even after having a tickets unassigned, it might appear on all open tickets.

Please find attached the screenshot of automation that we used.

[mararn1618 _secretbakery.io_]

Hi @Sanskruti Khandelwal ,

I'm working on a similar topic and don't think you can easily prevent the ticket from being created.

My current idea is to match tickets in the queue upon creation with custom code. If the code is confident enough to have found a match (e.g. 95% sure it's a duplicate or reply) it proposes to merge both tickets.

I'm not sure about the ideal solution for the last step though (how to best interact with the support agent) or if fully / semi automated would be best. Any thoughts?

[Angélica Luz]

Hi @Sanskruti Khandelwal,

Thank you for the details.

If the participant is replying to the customer notification that was sent from your reply to the ticket, the comment should be added to the original ticket.

Can you please check on the mail logs if they are using the exact same email to reply to the notification? Are the tickets being created with the summary, for example, “RE: KEY-123 Summary”? If that’s the case, it’s because they don’t have permission to comment on that specific ticket. 

Can you share with us a screenshot of the mail logs? Go to the mail settings and click on “View logs”. Just make sure to hide private information.

If the duplicated tickets have the “RE:” on the summary, then the automation can filter this: 

[Sanskruti Khandelwal]

Hey @Angélica Luz

Thanks for the reply

I'm able to resolve the comment issue where new ticket is generated for the same thread by changing certain permission of the customer and this in turn resolved the duplicate tickets.

Also, the mail handler is not able to catch all the mails from the catch email address. I tried checking logs for the same but for those mails there is no log even failure log. Not sure of what might be the issue here. 

FYI the mails I'm talking about is in the inbox folder of mailbox only

[Sanskruti Khandelwal]

Hey @Angélica Luz

Thanks for the reply

I'm able to resolve the comment issue where new ticket is generated for the same thread by changing certain permission of the customer and this in turn resolved the duplicate tickets.

Also, the mail handler is not able to catch all the mails from the catch email address. I tried checking logs for the same but for those mails there is no log even failure log. Not sure of what might be the issue here. 

FYI the mails I'm talking about is in the inbox folder of mailbox only

[Angélica Luz]

Hi @Sanskruti Khandelwal,

I’m glad that the issue regarding duplicated ticket is resolved.

The second issue about the mail handler, I believe you are using the mail handler of Jira Core that is not recommended for the Jira Service Management project since it has its own mail handler.

The mail handler created on Cog icon > System > Incoming mail it’s recommended only for Jira Software and Business projects. 

• Create issues and comments from email

[Sanskruti Khandelwal]

Hey @Angélica Luz ,

Thank you for the response.

I tried to set an email account at a project level, following the instructions from here  Add a custom email account, but I'm getting error shown in the image. 

Request you to help me resolve this. In the password field I've entered App Password as suggested in the document.

Also for the mails I mentioned earlier which the mail handler is not able to catch, there is a similarity between some of those mails, the subject of the mails has square brackets[] and even the logs are not there for these mails. Any particular reason for this.

Thank you in advance.

[Angélica Luz]

Hello @Sanskruti Khandelwal,

Thank you for sharing the details.

The error is related to an incorrect email or password. That’s the only cause for that. 

I searched for other errors on the logs but didn’t find anything else. 

Did you set up a 2-step verification for the account?

If it doesn’t have 2-step verification, have you tried to log in with the password (not the app password)?