Allowing comments from anyone with same domain as request participants?

[Benjamin Peikes]

We often have cases where a customer will open a ticket with us, and then CC: a group email address, either inside or outside their organization. The email address will be a service desk type email like "customer_service@otherorg.org".

The issue is that when the customer service agent replies, ie. "bob@otherorg.org" via email, a new ticket is created that just has that user as the reporter.

How do others solve this issue? We run into it all the time and we spin our wheels closing duplicate tickets and and trying to merge the information from the newly created ticket into the old.

There has got to be a solution for this problem.

[Angélica Luz]

Hello Benjamin,

Thanks for reaching out to Community!

When a customer creates a ticket, only the reporter will have access to the ticket in the customer portal and also permission to comment, unless they share the ticket with other customers or organization.

If a group of email like customer_service@otherorg.org  is added as a participant, only this address will have permission to comment on the ticket, it means that even if, for example, benjamin@otherorg.org  is part of this group and receives the notification and reply, the comment will create a new ticket because customer_service has permission and not Benjamin.

Is your project open to anyone with an account on the site and are customers allowed to create their own accounts?

If not, you can open your project, so if the customer already has access and reply to the notification, it should add a comment to the ticket.

Go to Project settings > Customer permissions > Who can access the portal and send requests to Service Desk project? > Anyone can send a request via the portal or support@domain.atlassian.net . 

Also, go to Jira settings > Products > Configuration > Can customers create their own accounts? > Yes, by signing up or sending a request.

If you don't want to open the project, the best option is to add everyone from the group to an Organization in the project, so customers will be able to share the ticket with the Org.

Regards,
Angélica

[Benjamin Peikes]

We understand how it works, the issue is that we end up with tons of duplicate tickets that we have to combine, and yes, we have an open site.

Here is the interaction that constantly causes issues:

1) Customer sends an email to support@ourcompany.com and CC:'s it_desk@theircompany.com

2) This creates a new ticket in Service Desk, let's call it T-1, and adds it_desk@theircompany.com as a request participant.

3) Bob from the clients IT desk responds to the ticket, but his email goes out as bob@theircompany.com. He may be adding information we need for resolving T-1, but because Bob's email is not it_desk@theircompany.com, it creates ticket T-2.

4) We have to then, 

a) Add bob@theircompany.com to T-1

b) Close T-2 as duplicate of T-1

c) Copy the information that Bob entered on T-2 into T-1, but because we add the comment, we lose some of the history to see everything.

The whole thing is awkward. At the least, there should be a way to take T-2, and combine it into T-1. For instance a "Service Desk Merge" function.

[Angélica Luz]

Thank you for the details, Benjamin.

Jira is not able to recognize when someone is in a group and automatically give this person permission to comment on issues.

There is a feature request suggesting the improvements for this:

• Allow JIRA ServiceDesk to Identify an Email is a group mail

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

[Benjamin Peikes]

@Angélica Luz - No, that is not what that ticket states. That ticket lists a solution to the problem that could never work because there is no way for Atlassian to know that an email address which was added to Request Participants via a CC: is a "group" email.

What we're looking for is the ability to add a domain/organization to a service desk ticket, which would allow anyone from that domain who commented to be added as a request participant automatically, instead of creating a new ticket.

Another option would be to give a "merge" ability in Service Desk. Let's say you have two tickets, one you call the "source" and the other the "destination". The source ticket would be the one that was accidentally opened as a new ticket. Merging would:

1) Add the reporter on source ticket to the request participant list of the destination.

2) Take all source comments, and add them to the destination.

3) Copy any linked tickets from source to destination.

4) Add a redirect, so any reference to the source ticket is treated like the destination (the same way moving a ticket between projects works)