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 @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?
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.
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?
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.
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:
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
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!
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?
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 )
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
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?
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:
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
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!
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?
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:
 - https://support.atlassian.com/jira-cloud-administration/docs/create-issues-and-comments-from-email/ (paragraph "Issue and comment creation")
On October 20, 2021, Atlassian published a security advisory for Jira Service Management. The full advisory is available at this link. We've seen a number of questions already asking for...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events