Forums

Articles
Create
cancel
Showing results for 
Search instead for 
Did you mean: 

Add request participants automation with a variable and JSON

Paola Benel
I'm New Here
I'm New Here
Those new to the Atlassian Community have posted less than three times. Give them a warm welcome!
August 11, 2026

Hello, I created an automation where I want to automatically add request participants using a variable, REST API, and JSON.

I found a problem: when I use the update operation to add a user to the request participants, I want to avoid overwriting the existing participants. However, it is still overwriting them instead of adding the new user.

I need to use a variable because the users are obtained dynamically from a Security Group in Microsoft Entra ID, and I don't know in advance how many users belong to the group.

Therefore, I need to add all the users from the Security Group to the request participants without overwriting the participants that are already there.

Does anyone know how I can achieve this using the REST API and JSON?

 

{
"update": {
"customfield_xxx": [
{
"add": {
"accountId": "{{participantAccountId}}"
}
}
]
}
}

2 answers

0 votes
Nil Pujolràs
I'm New Here
I'm New Here
Those new to the Atlassian Community have posted less than three times. Give them a warm welcome!
September 2, 2026

Hi Paola — I’ve actually been working on a small Forge prototype around almost exactly this problem.

Instead of rebuilding the participant list each time through Automation/JSON, the idea is to define a group and keep its members continuously synchronized with JSM Request Participants while preserving the rest of the participant list.

So when membership changes, the matching requests can be updated automatically rather than having to reconstruct the field each time.

I’ve already tested the technical prototype successfully on JSM Cloud, including reading group members and adding/removing Request Participants through Forge.

I’m now trying to find out whether this is useful enough to turn into a proper app. I’ve put up a small private beta here: jsm-group-sync.netlify.app

Your Entra ID use case is particularly interesting — if you’re still working on this, I’d be very interested to know whether continuous group → Request Participants sync would solve the problem you’re running into.

0 votes
Jean Horn
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Champions.
August 11, 2026

👋 Hi Paola,

The reason the "update" block with the "add" verb didn't work in your case is that the Jira API and Jira Automation don't always handle the update operation syntax well for all custom field types via the visual interface. Often, it ignores the instruction or attempts to overwrite the field using the standard "fields" structure.

To ensure this works reliably, instead of using the "update" node, we switch to the "fields" node and use Jira Automation's native loop to rebuild the list.

The ideal structure for your code is this:

{
"fields": {
"customfield_xxx": [
{{#issue.customfield_xxx}}
{ "accountId": "{{accountId}}" },
{{/issue.customfield_xxx}}
{ "accountId": "{{participantAccountId}}" }
]
}
}

What changes in practice:

  • The {{#issue.customfield_xxx}} loop: It iterates through the field, retrieves all users currently listed, and recreates the {"accountId": "..."} object for each of them.
  • The comma at the end of the loop: It ensures the JSON structure remains valid before the next item is added.
  • The last line: It inserts the new participant ({{participantAccountId}}) at the end of the list.

This way, you don't rely on the API's "add" operation: you provide the combined list (current users + the new one) yourself, and Jira updates the field while keeping everyone included!

I hope this helps. 😁

Suggest an answer

Log in or Sign up to answer
DEPLOYMENT TYPE
CLOUD
PRODUCT PLAN
PREMIUM
TAGS
AUG Leaders

Atlassian Community Events