Email replies in Jira Service Management: why a reply becomes a new request

How JSM Cloud decides: comment or new request

For every incoming email, Jira runs the same checks in this order:

1. A work item key in the subject. If the subject contains a key that matches an existing request, the email is treated as a reply to it. With several keys in the subject, the leftmost one counts.
2. The threading headers. Without a key, Jira compares the email's In-Reply-To and References headers with the Message-IDs it has stored for earlier emails. A match means: reply.
3. Who sent it. Even when one of the first two checks matches, the sender has to be allowed to comment on that request. If not, Jira creates a new request instead.

No key and no matching header: new request. That is the whole rule, and every mix-up below is one of these three checks going a way you did not expect.

Check what Jira actually received

Before changing settings, look at the email itself. In the project, go to Channels & self service, then Email, then View logs (older screens call this Email requests, View logs). Search for the work item key, open the ••• menu on the entry and download the raw email message.

Open the downloaded .eml file in a text editor. That is safer than a mail client because nothing in the email is loaded or run. In the header block at the top, note three lines: Message-ID (this email), In-Reply-To (the email it answers) and References (the earlier emails in the thread). The Message-ID can appear more than once when older messages are quoted; use the one in the header block. Then download the email that created the request and compare its Message-ID with the other two lines. A match explains a comment; no match and no key in the subject explains a new request.

"I replied, and now there are two requests"

The key disappeared from the subject. Some mail clients and some people rewrite the subject. If the key is gone and the reply did not keep the threading headers, the reply looks new. Atlassian notes that most duplicates come from a key that was stripped from the subject or from a reply sent as a fresh thread. Ask customers to reply to the notification instead of starting a new email, and leave the key in the subject.

The person replying is not on the request. Only the reporter, request participants and members of an organization the request is shared with can comment. The classic case: a customer copies a colleague, the colleague replies, and a new request appears. Three settings help, each with a different reach:

• Customer sharing (Project settings, Access, Customer permissions): let customers add other customers by email address, so people in To or Cc when the request is created become participants.
• The organization setting "Should new requests automatically be shared with a customer's organization?" (Settings, Products, Jira Service Management, Configuration, Organization management): colleagues in the same organization can then comment.
• The email setting "Allow all emails that contain a valid issue key to be added as a comment to the issue?" (Settings, Products, Jira Service Management, Configuration, Email). Set to Yes, anyone who emails a valid key can comment, including from an address the customer does not normally use. It is a site-wide setting, so weigh it before switching it on.

Two accounts with the same address. When a portal-only customer later also gets a full Atlassian account, replies can stop matching. In admin.atlassian.com, filter the users by that email address; if an active portal-only customer shows up, use ••• and Migrate to Atlassian Account. Check approvals and portal access afterwards.

The request is in a status that blocks comments. If the workflow status has a property that denies comments, a reply cannot be added and becomes a new request. Sometimes that is exactly what you want (see the next section); if not, look at the status properties in the workflow.

"A new email landed on an old request"

The customer replied to an old notification. It is quicker than writing a new email, and the headers point to the old request. Atlassian's advice is the plain one: ask people to write a new email for a new question.

A reused Message-ID. Mail clients, mail servers, automations, and templates or drafts based on an old email can carry an earlier Message-ID into a new email. Jira then matches it to the old request. Check automations and templates that send email to the project. An email re-sent with the same Message-ID is treated as a duplicate and creates neither a comment nor a request.

An old key in the subject. Recurring emails with a fixed subject can pick up a key. Add something that changes each time, such as a date or a client name.

Replies to closed requests. By default Jira accepts comments on closed requests, so a reply to a request that is done becomes a comment on it. To turn those replies into new requests, add the workflow property jira.permission.comment.denied with an empty value to your end statuses, such as Done, Closed, Cancelled and Declined. This blocks comments in that status through every channel: Jira, the portal and email. Atlassian describes the steps in How to process email replies to closed requests as new requests.

Outlook shows the thread differently

A separate question is how the conversation looks in the customer's mailbox. In the new Outlook, the customer's first email often sits apart from Jira's confirmation and later replies. That is about how Outlook groups messages, not about how Jira files them, and there is no Jira Service Management setting for it today. See Forwarding emails into Jira Service Management.

Keeping the evidence on the request

The raw email in the log is the proof of what happened, but it is not on the work item, and the log does not keep it forever. When a mix-up needs explaining later ("I replied, why is there a new ticket?"), attach the downloaded .eml to the request. A text editor is enough to read the headers.

Full disclosure: Dortus makes an app that helps here. MailView shows .eml and .msg attachments on the work item, and its Details tab lists every header of the email, including Message-ID, In-Reply-To and References, without downloading the file or opening a mail client. It does not read the email log and it does not change how Jira Service Management matches emails to requests.

Short answers

Does removing the key from the subject stop a reply from becoming a comment? Not always. If the reply keeps its In-Reply-To and References headers, Jira can still match it.

Why did a colleague's reply create a new request? Most likely they are not the reporter, a participant or in an organization the request is shared with, so they may not comment. See the three settings above.

Can replies to closed requests open a new request? Yes, with the jira.permission.comment.denied property on the end statuses. It also blocks comments in the portal and in Jira for those statuses.

Where do I see why an email went where it went? In the email log of the project (Channels & self service, Email, View logs). Download the raw email and compare the headers.

Questions

Seeing a case that does not fit any of these? Email support@dortus.com.