Duplicate JSM email requests caused by delayed Request Participant population

[Xinjie Hu]

Hi all,

We are seeing duplicate requests in JSM Cloud when multiple users are included in the same email thread.

---

Scenario

An internal user sends an email to our support address with several colleagues in To/Cc. JSM correctly creates the first request.

However, the other recipients are not always added to Request participants immediately. If one of them replies before JSM finishes adding them, their reply creates a new request instead of a comment on the existing request.

---

Example timeline

00:27 - Original email received
        → REQ-1 created
        → Request participants partially updated, but User B is not included yet

00:34 - User B replies directly to the original email
        → REQ-2 is created instead of a comment on REQ-1

00:42 - REQ-1 is updated again
        → User B is finally added as a Request participant

 The raw email headers look correct:

Original email:
Message-ID: <original-message-id>

User B reply:
In-Reply-To: <original-message-id>
References: <original-message-id>

 So the email threading information itself appears to be intact.

---

Environment & configuration

• Customer sharing is enabled 
• User B is eventually added automatically to the original request.
• The raw .eml confirms that Message-ID, In-Reply-To, and References are correct.

---

What I have tried

I tried to build an Automation workaround to add participants immediately after request creation. However, `{{issue.properties}}` only exposes the following propertie thus I could not find any property or smart value exposing the original inbound email To/Cc headers, so I cannot parse them myself and add the participants proactively.

jsm-chat
request.public-activity.lastupdated
request.channel.type
request.channel.email.source

---

Questions:

1. From what I understand, Request Participant population for email-created requests is asynchronous. Is a delay of approximately 15 minutes expected?
2. Could this delay cause the sender of a reply to fail the permission check and therefore create a new request?
3. Is there any supported Automation smart value, issue property, or API that exposes the original inbound email To/Cc recipients immediately?
4. Is there a recommended workaround for this race condition?

Thanks!

[Arkadiusz Wroblewski]

Hello @Xinjie Hu 

Please first go through https://support.atlassian.com/jira/kb/resolve-duplicate-ticket-creation-from-email-replies-in-jsm-cloud/ 

I think this has reached the point where Atlassian Support should inspect the backend email-processing timeline. The delayed participant population are more interesting here.

You or your Admin should Open Ticket because i think from here we will be more Guessing than troubleshooting. That need some backend Inspect.

Best,

Arek🤠