How to thread participant email replies as comments on existing tickets (not just Reporter)

[Nick Kempton]

Hi all,

I'm looking for advice on handling inbound emails from request participants in JSM.

The problem:

When the Reporter of a ticket replies via email to the project email address with the issue key in the subject, JSM correctly threads it as a comment on the existing ticket. However, when a Participant (someone added to the request but not the original reporter) replies in the same way, JSM creates a brand new ticket instead of adding their reply as a comment.

What I want to achieve:

Any email sent to the project email address that contains an existing issue key in the subject line should be filed as a comment on that ticket, regardless of whether the sender is the Reporter or a Participant.

My questions:

• Is there a native setting I'm missing that would allow participant replies to thread correctly?

• Has anyone successfully built an automation that does this? 

• Are there any third-party apps that handle this more elegantly?

Any guidance appreciated. Thanks!

[Anastasia Andriyanova _Teamlead_]

Hi @Nick Kempton

You’ve hit a classic Jira Service Management permission bottleneck.

According to Atlassian's email processing logic, JSM actually checks the Subject Line for the Issue Key first. However, immediately after finding the key, Jira performs a strict permission check on the sender's email.

By default, if JSM evaluates the sender as someone who doesn't have explicit rights to comment on that specific ticket (which often happens with certain Participant roles or external organization users depending on your project settings), Jira blocks the comment. Instead of dropping the email entirely, JSM's fallback behavior is to create a brand-new duplicate ticket.

How to handle this:

1. The Native Option (Bypassing Permission Checks): Go to Jira Settings -> Products -> Jira Service Management -> Configuration -> Email and enable "Allow all emails that contain a valid issue key to be added as a comment to the issue".

• The catch: This bypasses the user permission layer entirely. If any external user gets hold of a valid issue key (like SUPPORT-123) and emails your support line, their message will be added as a comment. For many security teams, this is a major compliance risk.

2. The App Way (Smart Mail Handling without Security Risks): If you want to keep your Jira permissions secure but still allow seamless collaboration for anyone in the email thread, you can offload this to CRM for Jira Cloud. We built a dedicated mail handler specifically to fix these communication gaps:

• True Subject-Key Threading: It links inbound emails strictly by the issue key found in the subject line. It bypasses the rigid JSM permission barriers, meaning your request participants can reply freely, and their messages will always land in the right ticket instead of creating duplicates.

• Flexible Participant Management: You can add any number of people to the conversation. If a new participant replies or someone is added to the CC field, the app automatically captures them and threads their reply into a dedicated CRM tab inside the ticket—no manual user configuration or permission tweaking required.

• Isolated Environment: External replies are safely kept within the CRM Communication tab, so external senders never touch or compromise your internal Jira project configurations, and you don't have to open security loopholes.

Hope this helps clear up the duplication mystery!

(Full disclosure: I’m part of the Teamlead development team behind CRM for Jira.)

Cheers,

Anastasia

[Arkadiusz Wroblewski]

Hello @Nick Kempton 

Theres also a lot of Official Documentation for your Use Case:

Resolve Duplicate Ticket Creation from Email Replies in JSM Cloud | Jira and Jira Service Management | Atlassian Support

Emails create comments instead of work items in Jira Service Management Cloud | Jira and Jira Service Management | Atlassian Support

Best,

Arkadiusz🤠