Email creating multiple tickets

[Dan Allenby]

Hi All,

We have moved to Jira Service Desk from another Ticket Management tool that relied on users emailing into a email address, which would log a ticket.  We have moved that mailbox into Jira so user's can do the same (we have built up a large customer base, so made sense to move the same mailbox over).   When a customer logs a ticket into Jira, we often ask them to go via the portal, however if our customer emails in, and there are other people on the email trail, every reply generates a new ticket.  Is there a way to get all replies logged into the one ticket rather than creating multiple?

Thanks,

Dan

[Jack Brickey · Accepted solution]

The issue most likely is that the users that are copied are replying to the original email and not to the email response from Jira. For a reply to be a comment on the existing issue the subject needs to contain the issue key.

[Dan Allenby]

Thanks @Jack Brickey  - Been doing some further digging around this, and from my understanding unless the users reply to the message from Jira, there is no way these can be added into comments unless manually done and every new reply to the original email will create a new request?

[Jack Brickey]

Well that isn’t actually the case of late. Certainly it is a safe means of ensuring a comment. However, as a test, give this a try. Create an issue by whatever means you like. Then in your mail client create and email with the JSM project email as the “To” and in the subject put the issue key, e.g. “abc-123 this is a test - comment or new issue?”. Add some text to the body and send away. Results? My expels that a comment will be added. If not report back and we shall discuss further.

[Dan Allenby]

Hi Jack,

Apologies for the delayed response.

We had an issue the other day, where a ticket was emailed in from one of our customers, with several people on the email.  A ticket was created into our service desk.  There were several replies to the email, with each new email creating a new ticket.  This only stopped, when we replied directly to a user on the ticket, and the communications were back and forth in there.  We did add the other users into the 'Request Participants' box, however these didn't get any updates.  

Below is a screenshot of our mail handler set up

Is there anyway to have all the request participants updated for each comment? and to stop the multiple emails for one request?

[Jack Brickey]

So the extra tickets were caused by the Cc individuals responding the the initial email rather than a notification back from Jira which would include the  ticked number in the subject. The Cc users would be added by the system to the Request participants IF you have sharing set up and the users exist as customers already or if you have it configured to add new users automatically. If that were the case then the “issue created” event notification would be sent to all users on the original email. Then if one of the users replied it would result in comment not a new ticket.

as long as you have a user as a RP then they should receive notifications on public comments if you have Customer Permissions set to notify.

[mararn1618 _secretbakery_io_]

Hi @Dan Allenby,

Not sure if this is solved for you, but I want to expand on @Jack Brickey's answer, since I just blogged about it and everything is still on top of my mind.

Question - Do you have (a) customer organizations and (b) request sharing set up?

If not, then what you experience is basically a permission problem:

• anna@company.com logs a ticket
• bernd@company.com replies via email
• JSM recognized beta a a different customer and if Anna's ticket is not **shared** with Bernd, then he is exempt from accessing / modifying that ticket => He is not allowed to add a comment.

To prevent this, the ticket needs to be "shared" with the people that should be able to add comments.

Ticket Sharing - Tickets can be shared in two ways

• Request participants: You can add another email address directly to the ticket as a 'request participant'. You have to do this for each ticket.
• Customer organizations: You can create a customer organization, add both email addresses to that organization and enable sharing within organizations. (more convenient)

Customer organizations are more convenient and they are set up like in the picture below. In addition you'll need to enable sharing within the organization (global settings: https://<YOURINSTANCE>.atlassian.net/jira/servicedesk/projects/<YOURPROJECT>/settings/customer-permissions).

If needed there are more details in the blogpost: https://www.secretbakery.io/posts/atlassian-jira/fixing-duplicate-tickets-from-email-with-organizations-in-jira-service-management/

Hope it helps!

[Jack Brickey]

Good info and nice blog article. You might consider creating an article here in the community and share the same contact. One question I have it’s been a while since I’ve tested this but it was my understanding that if a customer sends an email in and cc another user then if they are in the organization then they would automatically be added as a request participant. I seem to read in your article but that was not the case. Maybe I misinterpreted or maybe it doesn’t work that way?

[mararn1618 _secretbakery_io_]

I have just tested it and you're right: Emailadresses (a) on CC and (b) within the same organization will be added as a request participants. Other emailadresses (not within the organization) are dropped.

The point the article makes is however that cc'ing someone is not even needed to let them comment. An email address (not cc'ed; not a request participant) will be allowed to add comments to the ticket, based on being within the same organization. Since that point is be a bit confusing in my post I have updated it with your insights. :)

Regarding the article for the community: I would absolutely love to do that! I was a bit unsure if it would be okay to recycle the same content for that community article, but I understand it's fine? What about backlinks to the original post or into the marketplace? (ps. we really need private messaging in the community; don't like to spam other people with such questions )

[Jack Brickey]

Thanks for the update. I think it be great to add that article to the community. Regarding do use of links outside of the community I know that is generally frowned upon. Regarding links back to the marketplace I think that’s fine but I would defer to the guidelines https://community.atlassian.com/t5/custom/page/page-id/rules-of-engagement 

[Leon]

I have a similar problem as we are just starting to roll out JSM Cloud.

1) Jira does not know what email addresses are for what organisation until the agent manually added after a customer raises an issue

2) There are executives in organisations that always cc the other execs in (execs change randomly)

3) We do not want the whole organisation know what issues the execs are raising so therefore we do use the auto issue share feature.

4) Reviewing the above answers, if one exec emails in a ticket and cc'd in the other execs, the other execs will not be included and dropped off the issue. Therefore if the agent "replies to customer" through jira, the other execs will not be informed of the reply or realise there is an active issue in jira?

[mararn1618 _secretbakery_io_]

Hey @Leon, that sounds like the same scenario like over here: https://community.atlassian.com/t5/Jira-Service-Management/Request-participants-not-being-added-with-Email-CC/qaq-p/1726401#M80514

I think you can:

• Put all execs' emails in customer organizations
• Disable auto sharing

In this case execs can CC other execs and they will be added (because in the same organization), but because auto sharing is disabled other people cannot access the tickets.

– Cheers, Markus // Founder of Duplicate AI // Find & Merge Duplicate Issues

[Callum Carlile _Automation Consultants_]

Hi @Dan Allenby,

I'd check the settings in your incoming mail handler, perhaps you have the 'Create a new issue from each email message' selected, rather than this first highlighted option in the screenshot

[Dan Allenby]

Hi, @Callum Carlile _Automation Consultants_

Thanks for the response.

We currently have this set as 'Cloud Email Handler'.  What is the difference between this and the option you have highlighted above?

Thanks,

Dan

[Callum Carlile _Automation Consultants_]

I think this is just using some default settings that come with Jira Cloud.

There's more info here as to what the other 'Mail Handler Type' options are and how they process incoming emails, I'd suggesting trying to use one of these other options so that new tickets aren't created with each email.

Hope this helps!

[Foo Guan Sim]

The Cloud Email handler has the expected behavior (adds a comment into the issue if the mail contains the same mail ID [this is hidden in the source of the mail], or the Subject contains the ticket number, e.g. SUP-3322). @Dan Allenby what is the subject of the email that was received? Do they contain the same ticket ID in the subject?

Regards,

Foogie

[mararn1618 _secretbakery_io_]

Just a fun fact: The subject (e.g. "Re: ISSUE-1234") is irrelevant when people hit the reply button. What Jira uses in the "reply to email" case are mail headers:

Message-ID: <JIRA.71004.1517739365000.9.1547799482107@Atlassian.JIRA>

In-Reply-To: <JIRA.71004.1517739365000.9.1547799482107@Atlassian.JIRA>

[1] - https://support.atlassian.com/jira-cloud-administration/docs/create-issues-and-comments-from-email/ (paragraph "Issue and comment creation")

[2] - https://community.atlassian.com/t5/Jira-Service-Management/How-does-Jira-link-an-incoming-email-to-an-existing-Issue/qaq-p/983509

[Sara]

@Foo Guan Sim "adds a comment into the issue if the mail contains the same mail ID" can you confirm this is true? Where can I check this? I'd like to refer it to it on one of my Jira Support tickets. It'd be great help, thank you!

[Foo Guan Sim]

Hey Sara, you can check this by opening the email's source. In Gmail, this can be done by clicking on the triple dot on the top right of the email and then Show Original :

You should see a Message-ID similar to what mararn mentioned above.