How to add organization or Jira group members as JSM Cloud request participants

Decide which membership you mean

A customer organization on a request and a Jira group are different sources. Sharing a request with an organization is not the same operation as populating its individual Request participants. Decide whether you need the members of organizations already on the request, a particular organization, or a particular Jira group. Do not treat any of those as a reason to include everyone on the site.

Write down one test request, the intended people and an existing participant who must remain. Agree that list with the service owner before enabling a rule. Adding participants is an access decision; a broad membership source can include people who do not need that request.

Native Automation: members of the request's organizations

Atlassian documents an organization-members Automation pattern for Cloud. It loops through organizations on the request, saves each organization ID, retrieves members and appends their account IDs to Request participants.

1. Choose your trigger and restrict the rule to the intended service project and request types. Make sure the Organizations field is populated when the membership lookup runs.
2. Branch over the request's organizations and store the current organization ID. Send an authenticated GET to /rest/servicedeskapi/organization/{organizationId}/user on your own Jira site; wait for its response.
3. Use the returned account IDs in an advanced field update with add operations. Atlassian's example uses customfield_10025; find your own Request participants field ID rather than assuming that number.

Review paginated responses before calling the result complete. Preserve existing participants, check the Automation audit log, and compare the final field against your test list. Keep authentication values in protected configuration, not copied into tickets or screenshots.

Native Automation: members of a Jira group

Atlassian's group-members guide says you cannot select a group directly in Request participants. Its Cloud workaround resolves the group, reads its members and adds the individual accounts through Automation.

1. Create a Group picker custom field and populate it before the rule runs, optionally with a default group.
2. Use Send web request to resolve that group's ID through /rest/api/3/groups/picker, then retrieve members through /rest/api/3/group/member?groupId={groupId}. Wait for each response.
3. Edit Request participants using the response's account IDs. Retain the existing field value with the documented Copy from issue option so it is not overwritten.

This adds members present when the rule runs. Later group joins or departures are not retroactively synchronized with existing requests. Atlassian also warns that large groups can hit Automation limits. Inspect pagination and the audit log before assuming every member was added.

REST alternative for an existing integration

If you already maintain an integration, resolve the chosen membership source to individual account IDs, then use the JSM Cloud add-participants endpoint. It requires permission to manage participants on that request and accepts an accountIds array. A group name or organization ID is not that array.

Illustrative request shape, with placeholders:

Method and path: POST /rest/servicedeskapi/request/HELP-123/participant

Header: Content-Type: application/json

JSON body: {"accountIds": ["ACCOUNT_ID_1", "ACCOUNT_ID_2"]}

Authenticate using your approved integration setup. Read back the participants with GET on the same endpoint and compare the result. A successful response to one call does not validate membership lookup, pagination or a second overlapping rule.

App option: configure and preview participant rules

Disclosure: Atesen Software publishes this guide and makes Auto Participants for Jira Service Management. Native Automation and REST may already meet your needs. The app is an alternative interface for managing these rules, not an exclusive way to add members.

The Auto Participants documentation describes rules for request organizations, selected organizations or a Jira group. In Jira settings under Apps, scope a rule to a test service space and optional request types, choose its source and set a small per-request cap.

On Activity, use Try the rules on a request before a wider rollout. This preview shows counts and skipped reasons, not participant identities. Create a test request and inspect the actual participant field afterward. Agents also have an Add participants from rules action with preview and confirmation.

The app does not send notifications itself. Check JSM notification settings and verify the intended recipient's behavior separately; adding an account does not establish that an email was delivered.

Review Auto Participants on Marketplace

Before you widen the scope

Compare expected and actual people, including the reporter, existing participants and excluded accounts. Check what happens with an empty organization field or a larger group. Decide who will maintain the rule and how membership changes should affect older requests. Keep one owner for overlapping participant rules so an unexpected result can be traced.

This guide was checked against three Atlassian technical references and the public app documentation on 23 October 2026. It is documentation-based guidance, not a live tenant test. Atesen Software is independent of Atlassian. Return to all admin guides.