nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Avoid creating a new issue for a mail thread

unknown

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?

Accepted answers

All comments

Angélica Luz

Hello @[deleted],

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

unknown

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 @[deleted],

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?

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 @[deleted],

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:

Screen Shot 2021-02-19 at 14.44.28.png

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.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

cloud

jira-service-management