Resolve Duplicate Ticket Creation from Email Replies in JSM Data Center

Summary

In a JSM project, when a customer replies to a notification, the JSM mail channel should add a comment to the existing ticket. However, in some cases, a duplicate ticket is created instead.

Environment

Jira Service Management (JSM) Data Center 4.0.0 or any higher version.

ℹ️ This article is for the Data Center only. If you are working on JSM Cloud, please refer to Resolve Duplicate Ticket Creation from Email Replies in JSM Cloud

Solution

Explanation of how the JSM Mail Handler decides when to create a new ticket or add a comment to an existing ticket

The JSM mail channel examines various data from any incoming email to decide whether it should create a new JSM request or add a comment to an existing JSM request:

• If the JSM Mail Channel is able to detect any trace of an existing issue in an incoming email (via some of the headers of the email source), it will try to add a new comment to the existing JSM request, based on some conditions (more details on that below)

• Otherwise, a new issue will be created

⚠️ Note that the same logic is used by both the JSM mail channel and the Jira Mail Handler.

How does the mail handler look for traces of existing Jira issues in an incoming mail

The mail handler checks 3 places/headers in the source of the email to determine whether it should create a new issue or add a comment to an existing issue:

• The mail Subject line (Subject header):

  • The mail handler looks for an issue key in the subject, and if there is a matching issue in Jira, a comment is added to this existing issue. If no issue key is found, it moves on to the next step.

• The In-Reply-To and References headers:

  • The mail handler tries to detect if there is any message ID that is linked to an existing Jira ticket. If any message ID is found in the two headers above, the mail handler will analyze it and try to map it to an existing Jira ticket

  • If the message ID has the format "JIRA.12700.1562154694000.1.1562154780223@Atlassian.JIRA"

    • The ID after "JIRA" (in this case 12700) is compared to the ID column of the database table jiraissue.

    • If an existing row is found in the jiraissue table, then a comment is added to the existing ticket.

    • ℹ️ The message ID will have this format if a user replies to a notification email received from a Jira issue.

  • If the message ID has any other format,

    • this message ID will be compared to the ones stored in the database table notificationinstance.

      • This table contains all the email message IDs that have been associated with each Jira ticket (whether the email was used to create the issue or add a comment to that issue).

    • If there is a match, then a comment will be added to the corresponding issue.

    • ℹ️ The message ID will have a random format in case the user replied to an email that was originally used to create a new Jira issue.

Logic of the JSM Mail Channel

If the JSM Mail Channel detects that the incoming email is linked to an existing JSM request, it will try to add a comment on behalf of the sender of the email. Please note that it is only possible if the sender of the email has access to the JSM request by being:

• The reporter of the request

• A request participant for the request

• In any organization, the request is shared with

• Listed as approver of the request (in case the request was configured with an approval status)

If the sender of the email does not have a Jira account, does not have access to the Customer portal, or does not have access to the JSM request, the following will happen:

• No comment will be added to the existing ticket.

• Depending on various conditions, either the email will be dropped, or a new ticket will be created from this email.

Scenario One: The sender of the email does not have a Jira account, nor access to the JSM Customer Portal

Check if the sender of the email:

• has a Jira account (in the page ⚙ > User Management > Users)

• and also has access to the Customer Portal where the JSM Mail Handler is configured (as per the Project Settings > Customer Permissions setting)

If the email sender does not have access to the Customer Portal (or does not have a Jira account at all), go to the page ⚙ > Applications > Jira Service Management > Email Requests and check if the setting Public email comments is set to No.

If the Public email comments is set to No, use the following steps:

• Allow non-customers (external users) to add comments by email to requests they don't have access to.

• To do this, go to ⚙ > Applications > Jira Service Management > Email Requests and set the Public email comments setting to Yes.

Scenario Two: The sender of the email has access to the JSM Customer Portal, but does not have access to the JSM ticket

Check if the sender of the email:

• Has a Jira account (in the page ⚙ > User Management > Users)

• And also has access to the Customer Portal where the JSM Mail Handler is configured (as per the Project Settings > Customer Permissions setting)

If the sender of the email has a Jira account and access to the Customer Portal, check if this user is involved in the JSM ticket by being:

• The reporter of the request

• A request participant for the request

• In any organization, the request is shared with

• Listed as approver of the request (in case the request was configured with an approval status)

If this user is not involved in the ticket, use one of the following solutions:

Solution One

Add the sender of the email as a request participant to the existing JSM request.

This will allow the user to access the request and enable them to add comments to this ticket.

You can do this by opening the requests from the customer portal view and using the share button.

Please make sure that the setting Who can customers share requests with is set to Any customer or organization via Project settings > Customer permissions.

Please go through the documentation Managing access to your service project for more details about this setting.

Solution Two

You can also use organizations to achieve this:

• Create a new organization in the Customer Portal.

• This organization should include all the users who need access to the same tickets.

• Share the request with this organization.

By doing so, all customers in the same organization will be able to access and comment on requests shared with that organization.

Scenario Three: There is an invalid Field Context Configuration

There is a field in the configuration of the Request Type (associated with the JSM Mail Handler) that has an incorrect context configuration. To ensure that the Mail Handler works as expected and creates issues/comments from incoming emails adequately, the field context needs to include both:

• The Service Management project, this request is configured in

• and the issue type associated with the request type used by the Mail Handler

This issue is a side effect of the Service Management bug JSDSERVER-7061 - Removing the issue type context for a Service Desk field can break Request Types where it's in use

You can find more information and the solution steps about this in the KB article The JSM Mail Handler creates new tickets instead of adding comments to existing tickets due to invalid field context configuration.