Resolve Duplicate Ticket Creation from Email Replies in JSM Cloud
Platform Notice: Cloud Only - This article only applies to Atlassian apps on the cloud platform.
Summary
Jira Service Management creates duplicate tickets in response to customer email replies.
This article applies only to JSM Cloud. If you are working on the JSM Data Center, please refer to Resolve Duplicate Ticket Creation from Email Replies in JSM Data Center
Solution
Why do duplicates happen?
A reply email that doesn't include the original request's issue key reference (in the subject or body) is treated as a new request. Most duplicates come from clients who strip the [JSM-123] token or send a fresh thread.
Before we start
It's important to know some details on how Jira handles requests via email and determines whether 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 key matches an issue in Jira, it will update the issue and add a comment.
If that does not work, Jira will inspect the mail's header to find the Message-ID, In-Reply-To, and References values and attempt to link them to the ticket.
If neither of the conditions above is met, a new ticket is created instead. On the other hand, if either of those conditions is met, Jira knows to append this message to an existing ticket as a new comment. 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:
Best practices to avoid duplicates
Ensure the email channel keeps the issue key in the subject line (don't remove the
[KEY-nnn]token).Ask requesters to reply to the notification rather than starting a new email.
Check Space settings > Email for the processing log to confirm which emails created new issues.
Possible causes for Jira creating duplicated tickets
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
Resolving the duplicate Jira ticket problem
In the original ticket, the customer is not the reporter, request participant, or member of an organization that the ticket was shared with
In Jira Service Management, only the issue reporter, the request participants, and members of the organization with whom the ticket is shared 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:
Open your service project > Project settings > Access > 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 occur when a user with a 'Portal Only' customer account is later added as a full Atlassian Account. This can cause Jira Service Management to be unable to identify the correct account for actions such as commenting on tickets, assigning approvals, or viewing support requests. This results in inconsistencies, such as 'ghost identities' appearing in user pickers, approvals not visible in the portal, or requests becoming inaccessible. To resolve these conflicts, merge the Portal Only account into the full Atlassian Account to unify identities.
To determine if a customer has duplicate accounts and fix the issue, please follow these steps:
Users using the improved user management experience:
Go to admin.atlassian.com and select your organization if you have more than one. Then 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 in the left panel under the sites and products section, and choose the Portal-only customers option in the left menu on the next page.
Filter for the account's email address on the portal customers page. If it doesn't appear or appears 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. To resolve this, click on ••• > Select Migrate to Atlassian Account. This process merges the accounts and resolves any identity-related conflicts. After merging, verify that approvals are correctly assigned, and all support requests and approvals are visible in the portal.
Users without the improved user management experience:
Go to admin.atlassian.com and select your organization if you have more than one. Then 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 appears 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. To resolve this, click on ••• > Select Migrate to Atlassian Account. This process merges the accounts and resolves any identity-related conflicts. After merging, verify that approvals are correctly assigned, and all support requests and approvals are visible in the portal.
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 prevent Jira Service Management customers from adding new comments 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 > Request management > Workflow.
Find the relevant workflow, then 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:
To confirm it's working as expected, send a test reply and verify that it appends as a comment to the existing request rather than opening a new one.
Was this helpful?