Replies to Jira Service Management tickets result in duplicate tickets
Platform Notice: Cloud Only - This article only applies to Atlassian products on the cloud platform.
Problem
Jira Service Management creates duplicate tickets on email replies from customers.
Context
Before we start, it's important to know some details on how Jira handles requests via email and determines if a new ticket should be processed or a comment needs to be added to an existing one:
JIRA searches the subject for an issue key, if this matches an issue in JIRA it knows to update that issue.
If that does not work, JIRA will inspect the header of the mail to find the Message-ID, In-Reply-To, and References values, then attempt to link it to the ticket.
In case neither one of the conditions above is met a new ticket is created instead. On the other hand, if either one of those conditions is met, then Jira knows that it should append this message content to an existing ticket. Once we know that, there is one additional step that is taken by Jira in order to check if the user who replied to the email has permission to comment on the ticket, if the user does not have permission then a new ticket is created as well.
You can see more details about it in the document below:
Causes
In the original ticket, the customer is not the reporter, request participant, or member of an organization with which the ticket has been shared;
The customer is replying using a different email address;
The customer has duplicate accounts using the same email address;
The status has a property added to the workflow;
The customer replied after the ticket was moved to another service project;
Solutions
In the original ticket, the customer is not the reporter, request participant, or member of an organization with which the ticket has been shared
In Jira Service Management, only the issue reporter, the request participants, and members of the organization which the ticket is shared with are the customers who can comment on the ticket.
Request participants:
As mentioned in this document, anyone with access to the service project can add request participants by including the participant’s email address in the To or Cc field when creating the request. The permission to allow customers to share requests is managed by Customer sharing permission:
Company-managed projects: Open your service project > Project settings > Customer permissions > Customer sharing
Team-managed projects: Open your service project > Project settings > Channels > Customer permissions > Customer sharing
Under Customer sharing, select the option that best aligns with your project's needs:
Customers can search for other customers within their organizations, or manually enter the email address of other customers within their project
Customers can search for other customers within their project or organizations
More details about customer permissions can be found in the document below:
Customer organizations:
We can choose to share the request with the customer organization automatically or not by following these steps:
Select Settings, in the top right of the screen > Products
Under Jira Service Management, select Configuration
Within the Organization management section, in "Should new requests automatically be shared with a customer's organization?", we have two options:
Yes, automatically share email requests with the customer's organization. Requests sent from the portal will also be shared unless the customer selects otherwise
No, don't share email requests with the customer's organization. Requests sent from the portal will not be shared unless the customer selects otherwise
You can find additional information about customer organizations in the following document:
The customer is replying using a different email address
In this case, we have the option to allow external emails with a valid issue key to be added as a comment:
Select Settings, in the top right of the screen > Products
Under Jira Service Management, select Configuration
Under Email, you can select "Yes” to “Allow all emails that contain a valid issue key to be added as a comment to the issue?”
Refer to the following documentation for more details about this setting:
The customer has duplicate accounts using the same email address
Duplicated accounts usually happen when the user is added as an Atlassian Account after their portal-only customer account has been created, and this can result in Jira Service Management being unable to identify which user is trying to comment on the ticket via email, hence preventing comment being added to an existing ticket.
To determine if a customer has duplicate accounts and fix the issue, please follow these steps:
Users using improved user management experience:
Go to admin.atlassian.com and select your organization if you have more than one > Select Directory and Users.
Filter for the corresponding account's email address. If it doesn't show up, the user has no duplicate accounts and you can skip the next steps. If it shows up, proceed to the next step.
Select Products from the header, click your site's name from the left panel under sites and products section, and choose the Portal-only customers option on the upcoming page's left menu.
Filter for the account's email address on the portal customers page. If it doesn't appear or appear with the Inactive status, there are no duplicate accounts for this user. If it appears and has the Active status the user indeed has duplicate accounts and it’s necessary to click on ••• > Select Migrate to Atlassian Account.
Users without the improved user management experience:
Go to admin.atlassian.com and select your organization if you have more than one > Select Users in the sidebar.
Filter for the corresponding account's email address. If it doesn't show up, the user has no duplicate accounts and you can skip the next steps. If it shows up, proceed to the next step.
Choose the Jira Service Management option from the left menu.
Filter for the account's email address on the portal customers page. If it doesn't appear or appear with the Inactive status, there are no duplicate accounts for this user. If it appears and has the Active status the user indeed has duplicate accounts and it's necessary to click on ••• > Select Migrate to Atlassian Account.
In the issue view, one quick way to tell if you are dealing with an Atlassian account or with a customer account is to check its icon:
| Customer accounts use a gray icon. |
| Atlassian accounts use the user's initials on a color background or a picture set by the user. |
The status has a property added to the workflow
When using a workflow property, we can restrict new comments being added by Jira Service Management customers when the ticket is in the final status. In this case, if the status has a property that prevents new comments from being added, a new ticket will be created.
You can check if the status has a property by following the steps below:
Go to Project Settings > Workflow
Find the relevant workflow, then, on your right corner, click the pencil icon to edit it;
In Diagram mode, click on the status > Properties
You can see more details about each property and its use case in the following document:
The customer replied after the ticket was moved to another service project
Currently, after moving a request from Project A to Project B, there will be no notification email informing the customer about it. Thus, replying to a customer notification email will not update the request.
We have a bug report that has been raised with our developers, as you can see below:
- JSDCLOUD-9118 - Getting issue details... STATUS
We have some workarounds to help minimize this issue:
If you add a new comment on the request after you move it to a different Service project, the customer will receive a notification and a new thread will start.
You can also use an automation rule to do that automatically when the requests are moved to the second project, as you can see below:
