Email Request | Ticket Creation | One-to-many conversation

[Ayush]

Hi,

Once a ticket is raised using Email Request and some people are also added in CC then,

When the requester replies on the same thread (On Gmail)using the email id he used for creating ticket then those conversation are adding under the same ticket on JIRA.

But, when the person in the CC is replying to the same thread(On Gmail) then a new ticket is getting created on JIRA.

This will create confusion in the long run. As, multiple tickets will be generated having the same issue.

Kindly suggest any resolution to this.

[Andy Heinzer]

Hi Ayush,

I understand that you're using Jira Service Desk Server and that you have encountered a problem where some users are replying to an email chain; in turn you are wanting Service Desk to add those replies to an existing request, but instead it is creating new requests.

This happens because Service Desk is not yet aware that these individuals should have access to this request.  It tends to happen when a user creates a first email that has several to or cc recipients including one of which is the Service Desk mailbox.   When Service Desk gets that message, it will typically create this new issue, set the sender as the reporter, and then add all the to/cc addresses as request participants.  This Service Desk field that can be seen on the issue is the way that Service Desk is then able to grant other users access to this request.  Since by default Service Desk has a considerably higher privacy settings than say a Jira Core or Jira Software project does, it's necessary to make sure that Jira is aware of all the users that should have access to view/update this request.

What I see happens is that someone forwards that original email and then a new person replies to everyone else.  If Service Desk is setup to allow anyone to create their own account, the expected behavior is as you described where a new request is created because at the time that message is processed that specific user does not have access to the issue since they are not in the request participant field.

The way I would suggest to try to avoid this problem requires some behavior modification of the users themselves.  Instead of sending a mass email to a number of users including Jira's mailbox, I find it can help to first create the issue in Jira Service Desk instead.  When you get an email notification from Jira that this request has been created, you can then reply to that specific message and then include all the addresses you want in the CC field.  When Service Desk gets this request from the reporter/sender, the default behavior is to add all those users as request participants.  This grants those users the access needed to see and update the request, but in turn will prevent them from creating their own requests by the same title when they reply to the message.

The tricky part can be making sure that new users that get this email later on are getting added to this Service Desk request before attempting to reply to this email conversation.  Service Desk cannot be aware of additional users added to an email thread if Jira doesn't get that message as well.  Certainly Service Desk agents can add new users to a request, and depending on the project settings, the reporter or other existing participants can do this as well in the customer portal directly as well. 

Could you also please let me know what version of Service Desk you have?  I ask because some versions handled this scenario slightly differently in the past.

Thanks

Andy

[Ayush]

Hi Andrew,

Hope you are doing great!

Firstly, I am using JSD Cloud. The solution you offered seems very nice. But, it will not help in achieving our motto. I will provide you with a detailed example on what we want to achieve and then if any alternative is possible you can suggest a solution.

Example:

Step 1: Whenever a person sends an email to the JSD Email id (Provided by JIRA) a ticket is to be created ---This is achieved (I have already enabled the public signup from Configuration)

Step 2: If in the email that person has also added a few more people (In CC and To), then whenever any one of them replies to this then it should be added to the same request thread in JIRA. ---A new ticket is created (As you mentioned it correctly above)

Also, I just wanted to confirm once again that when I enable public signup from configuration. The Requester will just be able to see his tickets and will be redirected to the JSD Portal?

Looking forward to an early response.

[Andy Heinzer]

Hi Ayush,

Thanks for clarifying here.  It seems your questions was tagged with the jira-service-desk-server and server tags.  It's good to know that you are using the Atlassian Cloud platform here as the behavior could be slightly different between Cloud and Server.

In this case, there are actually two different locations you will need to configure to be able to have the requester add new users to the request via an email To: or CC: field.

1. The first is the global settings that allow customers to create their own accounts.   This tends to be necessary unless your Jira Cloud site already has all accounts created for all of the email addresses that this user my try CC in the message.  You can reach this at the URL $JIRAurl/secure/admin/SDConfiguration.jspa
   
2. You will also need to check a pair of settings on the project settings level for this to work.  You can reach this at $JIRAurl/servicedesk/admin/{ProjectKEY}/customer-permissions  On this page, you will need to make sure that these new accounts both have access to the project AND that the requester is permitted to share this request with them.  In this case I think the project settings will need to look like this:
   

Only with these settings do I believe that your original requestor will be able to add these additional users to the same request directly via the email To/CC fields.  Otherwise I would expect that these other users would still not be added to the request participants field of that issue. If that happens, they can't see the request and their comments cannot be added to that original issue.

I hope this helps.

Andy

[Ayush]

Hi Andrew,

I really appreciate your help and the solution that you provided. It helped me solve a few problem that I was facing.

But, I am still stuck at one problem that when the Requester has put a gmail group email in cc(This group mail has multiple email id added to it). So, when any person is in this group replies to this email, a new ticket is being generated. Can you help me solve this problem? 

[Andy Heinzer]

Yay! Glad to hear that helped.

As for the group email addresses being used: oof, that specific scenario is still something that Service Desk Cloud and Server cannot yet handle in the most graceful way yet.  Service Desk is only able to identify user accounts by their email address when it comes to processing messages and sending notification emails.

If a requester CC's a distribution email address Jira has no way to understand this address is not an actual person or a single account.  So Jira will try to treat that address as if it was as single user.   That can work for sending notifications, but as you have noted, it does not work so well for the email users on the other end that then reply again.   There is a feature request for Jira to better handle this in JSDCLOUD-4627 and JSDSERVER-4627.  The title of that request is to 'Allow JIRA Service Desk to Identify an Email is a group mail'.   I would recommend watching those issues for updates here.  Right now, it's not possible for Jira to see that address as a group address.

If you can't avoid using those distribution/group email addresses with Service Desk, then I would suggest to try to implement Service Desk Organizations here.  With these organizations, you could share the request with an entire group.  This is another way to grant access to a request apart from the request participants field.  More details in Jira Service Desk: Grouping Customers into Organizations.   This approach would require a bit more work to build out and keep updated all the users in organizations, but it could help here in regards to being another way to share requests with team members that need to be included and/or have the ability to comment on an existing request.  It would require either the customer, a requested participant, or an agent to share this request with that organization before hand, but this could help.   Sharing to an organization is something that has to happen in the customer portal or in Jira itself, this is not something the email handler is going to be able to manage here.

Andy

[Ayush]

Hey Andrew,

I believe the Organization feature will not be of great help to us. Also, there are two things that I noticed - 

1. Let's say if a requester is sending a mail at abc@xyz.com (abc@xyz.com is set for Email Request). So, when a comment is made on this ticket on JIRA, comment is reflected in the automated mail received by JIRA to the participants involved (CC And To) but nothing is communicated to abc@xyz.com. 

This creates a communication gap if we are using a mailing list as other people in the mail are still unaware that whether an action has been taken on this or not. 

I hope I was able to explain the problem.

2.  When the person in CC is replying to the original email (The one received from the Requester and not JIRA) then this comment is being reflected in the ticket as well, which is really great.

But, when the person in To is replying, then no comment is being shown in the ticket created on JIRA.

This once again creates a communication gap as some messages are getting missed in the thread.

3. Is it possible that when the reporter replies to the ticket (Via Comment) this comment be visible on the original requester email and not the automated one received from JIRA. As, this makes handling two mails focussing on the same issue very hectic.

I really appreciate your help.

Regards,

Ayush Agrawal

[Andy Heinzer]

Hi Ayush,
Sorry for the delayed response, I'm afraid I missed your previous reply.

For point #1: That is by design. Jira Core typically does not notify users of events/actions that they took directly. In Jira Core these kinds of notifications are something users can choose to get or not by adjusting their user profile. However for Service Desk, the user profile does not have this option. I think I understand your point here, but I would argue that there is not a communication gap in this specific instance. Because the user that sent the message is already aware of the contents (at least I hope they know what they wrote). It's only the other users on the request that need the notification in order to be aware of that message. Perhaps I'm being overly technical in the assessment here, but I think I can still see the value in some cases that I think you're pointing out here. There is an existing feature request for this, specific to Service Desk Cloud in JSDCLOUD-2096

For point #2: I have not been able to recreate that specific behavior you reference here. In my testing the To or CC field doesn't make a difference in regards to how that message is processed, just as long as the email itself does still include the email address in the to/cc field that service desk is using to process mail for that project.

#3: If I understand your request here, you are seeking some means to have service desk update this original email thread. While service desk will send notifications of this comment/change to all the users on the request, it has no control over these external message that can be sent to any number of recipients that can change at every step. I understand that using service desk with a large group of customers on a single request that are either unaware of the service desk customer portal itself, or that only want to utilize their email to manage such requests can make this very difficult to manage. What I would recommend is shifting users to utilize the Service Desk customer portal more often and directly instead. Service Desk is designed to keep requests private and only between the parties that it is aware of, that should have access. That directive is not easily overridden in Service Desk.

I hope this helps.
Andy