We have an issue where our clients open Service Desk tickets with us via email, and use the CC: field to include email addresses which are actually group addresses, i.e. bob@companyA.com, is on a team_B with frank@companyA.com and ralph@companyA.com.
Bob opens a ticket, let's call it TICKET-04, by sending an email to our support email, and will CC: team_B@companyA.com, so that the people on their side get notification of the creation of the ticket. The problem is that when frank@companyA.com replies, because their email is not team_B@companyA.com, a new ticket is opened. We then have to close that ticket as a dupe, and then add that person as a request participant.
In addition, it means that the original ticket does not have the comment.
Any ideas on how to deal with this?
Service Desk is pretty strict in regards as to which users can view/comment on an existing request. From the customer side of things, only the reporter, requested participants, OR users in a shared organization can view/comment on those issues. When it comes to processing emails for requests, Jira Service Desk is only able to look at the from email address in order to try to tie that email address to a specific user's account info in Jira.
In this case, Jira Service Desk doesn't know that firstname.lastname@example.org got that email sent to a distro list in team_B@example.com As far as Service Desk knows, only team_B@example.com was in the CC and in turn is in the request participants field. Hence, Frank doesn't have permissions. And since Service Desk does not have a problem with that user creating their own request by the same name, it will do just that.
The solution I would recommend is to try to help try your customer to overcome this by either
A) Have the customer that created the request add the individual users to request participants
B) Have the customer share the service desk request with the organization Frank is in. Check out Group customers in organizations and Setting up Service Desk users: Manage organizations for more details. (Doing this before they forward the email to that distro list can help prevent this problem as well).
I think using option B is better in the long run, but it will be more work from a Jira Admin side to setup all those organizations and keep them managed. Basically, we need the customer be more explicit in telling Service desk exactly which users can view/comment here.
We can’t do that. The initial user at the client doesnt even know everyone in the group.
Imagine that they are CC:ing their own service desk, and then someone from that team responds.
That team might have 50 people. I cant put them all in as customers.
Maybe their could be wildcard support for Organizations, ie, and organization could include anyome with email from particular org.
Another, more ideal solution would be to have a way to “merge” tickets.
ie if this person responds, and creates a new ticket, the assignee could just merge it into the original ticket, which would basically take the Description, and add it as a comment by the reporter, and add thr reporter as a request participant.
I understand it does not seem feasible to add all those individual users as customers to Service Desk, but I think this is one way to help avoid this problem. If Service Desk both has knowledge of that email address as a user account and the issues is shared with that user's same email address, then it can handle this scenario. But Service Desk has no knowledge that this is a distribution list.
You make a good point that the use of organizations would be helpful here if we could add all users from a specific domain. Unfortunately, that is not something that Service Desk organizations can do today. There is a feature request for this in https://jira.atlassian.com/browse/JSDCLOUD-4519
There is also another separate feature request for the ability to merge issues in Service Desk in https://jira.atlassian.com/browse/JSDCLOUD-4685
In retrospect, the only way to support this well is a merge that adds the user from the merged ticket as a request participant.
Organizations dont work, as some customers have separate departments which shouldnt be able to see each others tickets.
As I said, we cant add all of the customers email apriori. Adding them is NOT a way to solve the issue.
The merge solution also helps in the cases where a user has two email addresses or the email address they send from changes.
Hello Community 👋, I'm a product manager at Atlassian, looking at improving change management capabilities across our products. In particular, we're looking at bridging the gap between Dev & ...
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