JSM Automation - Multiple Request Participants from comma-separated emails using an Advanced Branch

Question

Hi everyone,

I am investigating an issue in Jira Service Management Cloud related to populating the Request participants field from a text field containing multiple email addresses separated by commas.

I was able to reproduce the behavior in a test environment and isolate the issue.

The automation flow is:

* A text field receives multiple email addresses separated by commas.
* An Advanced Branch iterates over the values using a smart value similar to:{{issue.FIELD_NAME.replace(" ","").split(",")}}
* For each email, the automation calls:
GET /rest/api/3/user/search?query={{emailParticipante.urlEncode}}
* The request returns HTTP 200 and a valid accountId.
* The automation then calls:
POST /rest/servicedeskapi/request/{{issue.key}}/participant

Request body:

{ "accountIds": [ "{{webResponse.body.first.accountId}}" ] }

The issue is that when multiple emails are processed, only one participant remains in Request participants, even though both GET requests return valid users and both POST requests return HTTP 200.

I also tested storing the accountId in a variable inside the branch:

accountIdParticipante = {{webResponse.body.first.accountId}}

Then I used:

{ "accountIds": [ "{{accountIdParticipante}}" ] }

In this case, each branch preserved the correct accountId, but the final result still contained only one participant.

As a comparison, I tested a single POST request with multiple fixed accountIds:

{ "accountIds": [ "accountId1", "accountId2" ] }

This worked correctly.

HTTP 200 was returned, the response showed size=2, and both participants were successfully added to Request participants.

Because of this, my current hypothesis is that the issue is related to parallel execution of Advanced Branch iterations, where multiple updates to the same request may interfere with each other.

I also tested using an auxiliary text field to accumulate the accountIds before performing a single POST request, but the updates inside the branch were still inconsistent.

Has anyone successfully implemented a similar scenario?

I am mainly looking for guidance on:

* How to reliably resolve multiple email addresses into accountIds and then perform one single POST.
* Whether an Advanced Branch can be processed sequentially.
* Whether there is a recommended way to collect values from multiple branch iterations.
* Whether using two chained automation rules would be a better approach.
* Whether there is any known limitation involving webResponse, variables, or updates performed inside parallel branches.

Any examples or guidance would be greatly appreciated.

Thanks!

Andrea Robbins · Accepted Answer

Hello!

Here is a link to a documented solution:

https://support.atlassian.com/jira/kb/add-update-remove-request-participants-using-automation-in-jsm-cloud/

In other words, keep the advanced branch so it loops through each user to get the email address, and use the advanced JSON within the edit work item action to just add the user incrementally (currently based on what you are experiencing, it is being set instead of just updated/added):

{"update": {  "Request participants": [  {  "add": {"id":"<accountId>"}  }  ]  } }

Josh · Accepted Answer

This is a common JSM Automation footgun. Request participants expects Atlassian account / customer identities (or accountIds), not raw email strings — and Advanced Branch behaviour depends on whether each iteration actually resolves to a user the project can add.

Pattern that usually works:

* Split the comma-separated text into a list (smart value split on ,, then trim whitespace). Put that list into Advanced Branch → For each.
* Inside the branch, resolve each email to a user/customer before Edit issue. Options that work in practice:* If they are already portal customers / site users, use a Lookup issues / Lookup users style step where available, or an intermediate web request to /rest/api/3/user/search?query={{email}} and then set participants from accountId.
* If they are not customers yet, add them as customers first (Invite / Add customer action) then add as Request participants.

* Avoid stuffing the raw email string into Request participants in one Edit — that often silently skips or only takes the first value.

Also check: field context (Customer Request Type vs internal), whether the automation actor can browse users, and audit log on the rule for “user not found” / permission errors per branch iteration. If you can paste a redacted smart-value dump of one branch item (email + resolved object), we can confirm whether you’re still passing a string vs an accountId.