Comparison

Adding JSM Request Participants: Native Jira Automation vs ParticipantFlow

Published by ASUNOKI, the developer of ParticipantFlow for JSM Applies to Jira Service Management Cloud Checked October 2026

Disclosure: this page is written by the developer of ParticipantFlow for JSM, so read it with that in mind. Part 1 is useful on its own — it describes what you can do with Jira Automation without installing anything.

The Request participants field in Jira Service Management is a user picker. It accepts people, not groups, and it does not accept email addresses that are not already linked to an account. This page compares the ways to fill it from a Jira group, from a list of emails, or from account IDs.

01 What native Jira Automation can do

Everything below uses features that ship with Jira Automation. The two Atlassian articles this section is based on are linked at the end.

Add the members of a group

Atlassian’s knowledge base describes this workaround, because selecting a group directly in the field is not supported (the feature request is JSDCLOUD-1268):

1. Create a Group picker custom field in the service project and hold the target group in it (it can be the field’s default value).
2. Add a Send web request action that calls the Jira groups-picker endpoint to get the group ID. It uses Basic authentication with an email address and an API token.
3. Add a second Send web request that calls the group-members endpoint with that group ID.
4. Add an Edit work item action that sets Request participants from the account IDs in the response, using the option that keeps the existing values.

Atlassian notes that the rule adds the members present when it runs, that later group changes are not synced to existing requests, and that very large groups can exceed automation execution limits.

Add people you already know

• Edit work item with the Request participants field: pick users, or copy from another user field, and choose the option to add to existing values.
• Edit work item with advanced JSON using add/remove and account IDs.
• Send web request to the Service Desk participants endpoint with a body of account IDs.

Add people from email addresses

Email addresses cannot be written to the field directly. Atlassian’s article splits the addresses, loops over them, calls the Jira user-search API for each one to get an account ID, and then edits the field. A person without an account in the site has no account ID to add.

Several threads on the Atlassian Community report that this loop can leave out some of the people when many addresses are processed, for example this 2026 discussion. The suggested explanation is that branches run in parallel and overwrite each other. Whether you are affected depends on how the rule is built, so test with more addresses than you expect to use.

02 Side by side

Topic	Native Jira Automation	ParticipantFlow for JSM
Add the members of a Jira group	Possible with a group picker field, two web requests and an edit action.	One action: enter a Jira group name or ID. Adds active members, up to 500 per run.
Add from email addresses	Possible with a loop, a user-search web request per address and an edit action. Reported to be sensitive to parallel branches.	One action: paste a comma- or newline-separated list. Addresses that match no single user are skipped and reported.
Add from account IDs	Edit work item (JSON) or a web request.	One action. The IDs are sent to Jira in one batch, so one invalid ID makes the step fail.
Existing participants	Kept if the action is configured to add to existing values; a misconfigured edit can replace them.	Never removes or replaces participants. People who are already participants are skipped.
First setup	Custom field, web requests, headers, JSON and variables to build and test.	Install, add the action, click Connect, fill in three fields.
API token / web requests	Needed for the group and email methods (Basic authentication with an API token).	Not needed. The action runs with the permissions of the account that clicked Connect.
Permissions	The credentials you use in the web requests must be allowed to read the group and edit the request.	The group source needs the connecting account to have the Administer Jira permission. Email and account ID sources do not.
Ongoing maintenance	You own the rule: API token management, field changes, Atlassian changes to the documented method.	The app is maintained by its developer. You still own the rule that calls it, and the connecting account must stay valid.
Cost	Included with Jira Automation (subject to your plan’s automation limits).	Paid app via Atlassian Marketplace with a 30-day free trial.

03 What ParticipantFlow does not do

• It does not remove participants. It only adds.
• It is not a continuous sync. Like the native method, it adds the group’s members when the rule runs. Later changes to the group are not applied to earlier requests.
• It reads Jira groups only. A Jira group is not the same thing as a group in an external directory such as Microsoft Entra ID. The group source only works with a group that exists in Jira; how an external group appears in Jira depends on your identity setup.
• The group source adds Jira users. Portal-only customer accounts cannot be members of Jira groups. Use the email or account ID source for them.
• Results depend on your site. Resolving an email address to an account and adding a participant depend on permissions and settings such as profile visibility and who the request allows as participants.
• Adding participants has side effects. Participants can receive notifications and can see the request in the portal according to your project settings. Test with your own accounts first.

04 Which should you use?

• If you add a handful of known people, or you already maintain a working rule, native Automation is probably enough.
• If you often add whole groups or long email lists, or you do not want to manage an API token and web requests in each rule, ParticipantFlow reduces the setup to one action.
• Whichever you choose, run it first on a test request and check the rule’s audit log.

To try it, see the Quick start or the Atlassian Marketplace listing.

05 Sources

• How to add group members as request participants (Atlassian support, updated July 2026)
• Manage request participants with automation in JSM Cloud (Atlassian support, updated June 2026)
• JSDCLOUD-1268 (feature request: select a group in Request participants)

Atlassian may change these methods; check the linked articles for the current steps.