Documentation

ParticipantFlow for JSM documentation

Vendor Seisuke Nagahara Contact support@asunoki.jp

ParticipantFlow for JSM adds one action to Jira Automation: Add Request Participants (ParticipantFlow for JSM). It adds Request Participants to a Jira Service Management request from a Jira group, a list of email addresses, or a list of account IDs — without an API token or a hand-built Send web request step. This page covers setup, each setting, the output smart values, what the action does and does not do, and troubleshooting.

ParticipantFlow for JSM is available on the Atlassian Marketplace. Back to the documentation index.

Comparing it with the native Jira Automation method? See Native Jira Automation vs ParticipantFlow.

Quick start

A short path from installation to a first successful run. How long it takes depends on your site; use a test request so no real customer is affected.

1. Install. A Jira administrator opens the ParticipantFlow for JSM listing on the Atlassian Marketplace and chooses Try it free, then selects the Jira Service Management site.
2. Create a rule. In your Service Management project go to Project settings → Automation → Create rule. For a first test choose the Manual trigger (it adds a button to the request’s Automation menu).
3. Add the action. Choose Add component → Add action and search for Add Request Participants (ParticipantFlow for JSM).
4. Connect. Click Connect in the action. The action then runs with the permissions of the Atlassian account that connected it. No API token or password is needed.
5. Fill in the fields. Issue Key {{issue.key}}, then set Source to one of group, emails or accountIds and fill in only the matching field:
   • group — a Jira group name or ID, for example support-team.
   • emails — for example user1@example.com, user2@example.com.
   • accountIds — for example 5b10ac8d82e05b22cc7d4ef5.
6. Show the result. Add an Add comment to work item step (set it to internal) with the text Request participants updated. {{updatedJiraResult.summary}}. Save and turn the rule on.
7. Run it on a test request. Open a test request, click the Automation (lightning) button and run the rule. The comment shows a summary such as Added: 1 / Skipped (already participants or duplicates): 0 / Failed: 0. You can also check the rule’s Audit log for errors.

01 Adding the action to a rule — details

1. Open the Jira Service Management project you want to automate, then go to Project settings → Automation (Jira administrators can also create a global rule from Jira settings → System → Automation).
2. Create or edit a rule. Choose a trigger that gives the rule a Service Management request — for example Manual trigger, Work item created, or Work item transitioned.
3. Click Add component → Add action and search for Add Request Participants (ParticipantFlow for JSM).
4. The first time you use the action in a rule, click Connect. This links the action to your Atlassian account so it can call Jira on your behalf; no API token or password is entered.
5. Fill in the fields described below and save the step.
6. Add later steps (for example Add comment or Send email) that use the action’s output.
7. Turn the rule on. A Manual trigger rule can then be run from the request’s Automation (lightning) menu.

02 Action settings

Field	What it does
Issue Key	The Service Management request to update. Usually {{issue.key}}, so the action runs against the request the rule was triggered on.
Source	Which one of the three inputs below to use. Type group, emails, or accountIds. Only the field that matches the Source is read; leave the other two empty.
Group name or Group ID	Used when Source is group. Active members of the Jira group are added (see the limits below).
Email list	Used when Source is emails. Comma- or newline-separated, for example user1@example.com, user2@example.com. Each address is looked up as an exact match and converted to an account ID.
Account ID list	Used when Source is accountIds. Comma- or newline-separated Atlassian account IDs, for example 5b10ac8d82e05b22cc7d4ef5 (or qm:…:… for some portal accounts).

03 What the action does — and does not do

• It only adds. The action reads the request’s current participants first and adds only the people who are not yet participants. It never removes or replaces an existing participant.
• Duplicates are skipped. Running the same rule again on the same request adds nobody new; people who are already participants are counted as skipped. Repeated entries in your input are collapsed.
• Unmatched emails are skipped and reported. An email address that cannot be matched to exactly one user is listed in failedValues and does not stop the other addresses.
• Account IDs are sent as one batch. If any account ID is not valid for the request, Jira rejects the whole batch, no participant from that run is added, and the rule step fails with an error. Check IDs before running.
• Group source = licensed Jira users. Portal-only customer accounts cannot be members of Jira groups, so the group source adds members that are Jira users. Use the email or account ID source for portal customers.
• Group members are capped at 500 per run. If a group is larger, the first 500 are used and the summary says the list was truncated.
• Jira may notify participants. Request participants can receive notifications about the request and can see it in the customer portal, according to your project’s notification and permission settings. Add only people who should have access to the request.
• Runs as the connected user. Every Jira call is made with the permissions of the Atlassian account that connected the action (the Connect step). The request must be one that user can edit participants on.

04 Using the output

The action returns the smart values below for use in later steps of the same rule. In Automation, the result is named after the action’s verb, product and entity: it appears as {{updatedJiraResult}} in the smart-value picker. Confirmed on a live site:

Smart value	Contents
{{updatedJiraResult.addedCount}}	Number of participants newly added in this run.
{{updatedJiraResult.skippedCount}}	Number of people who were already participants (not added twice).
{{updatedJiraResult.failedCount}}	Number of inputs that could not be resolved.
{{updatedJiraResult.addedAccountIds}}	Account IDs that were actually added.
{{updatedJiraResult.failedValues}}	The inputs that failed, with the reason.
{{updatedJiraResult.summary}}	A one-line summary, for example Added: 1 / Skipped (already participants or duplicates): 0 / Failed: 0.

Example: group → request participants

Trigger: Manual trigger
Action:  Add Request Participants (ParticipantFlow for JSM)
           Issue Key: {{issue.key}}
           Source: group
           Group name or Group ID: support-team
Action:  Add comment to work item (internal)
           Request participants updated. {{updatedJiraResult.summary}}

Example: emails stored in a long text field (verified on team-managed JSM)

This setup was tested on a team-managed Jira Service Management project (October 2026):

1. The request type has a Paragraph (long text) field named Participant Emails. The requester enters comma-separated addresses, for example a@example.com,b@example.com.
2. A rule with a Manual trigger runs Add Request Participants (ParticipantFlow for JSM) with Source emails and Email list {{issue.Participant Emails}}.
3. With seven addresses in the field, one run reported Added: 7 / Skipped (already participants or duplicates): 0 / Failed: 0 and all seven people appeared as request participants.

What was not tested: reading the answers of a Jira Service Management Form directly. Atlassian’s documentation says form smart values are available with the Form submitted trigger; in this test a form answer read with a manual trigger came back empty, so if your emails exist only in a Form question, make sure they reach a Jira field or variable that the action can read. Re-running the action on the same request in the team-managed project was not tested; duplicate skipping was verified on another project.

Conditions for email lookup: each address is looked up as an exact match by the Atlassian account that connected the action, and it must match exactly one existing account in the site. Whether an address can be found depends on that account’s permissions and on the profile and account settings of the person you are adding. Addresses that cannot be matched are skipped and listed in failedValues. The test used fictional customer accounts, so results for other account types may differ.

Example: report unmatched emails

Condition: {{updatedJiraResult.failedCount}} greater than 0
Action:    Add comment (internal)
           These addresses could not be added: {{updatedJiraResult.failedValues}}

05 Permissions

When you install the app, Atlassian asks you to approve the following access:

• read:servicedesk-request and write:servicedesk-request — read and update the Request Participants of a request.
• read:jira-user — look up a user by email address.
• manage:jira-configuration — needed only for the group source, because Jira’s Get users from group API requires Jira administrator permission. The app does not change any Jira configuration.

The app has no external server and stores no data outside Atlassian’s Forge platform.

06 Troubleshooting

• The group source fails with a permission error. Reading group members requires the Atlassian account that connected the action to have the Administer Jira permission. Reconnect the step with an administrator, or use the email or account ID source.
• “The specified group was not found”. Check the group name or group ID. Group names must match exactly.
• Some emails are listed in failedValues. The address did not match exactly one user. Check for typos, or use the account ID source. The other addresses are still processed.
• “The JSM API returned an unexpected response (status: 400)” with the account ID source. At least one account ID is invalid for this request. Remove or correct it and run the rule again.
• Only 500 members were added from a large group. This is a fixed per-run cap. Split the group, or run the rule with a smaller group.
• A smart value appears as literal text. Use {{updatedJiraResult.…}} and place the step that uses it after this action in the same rule. Open the smart-value picker in a later step to see the available names.

07 Related documents

• ParticipantFlow for JSM on the Atlassian Marketplace
• Native Jira Automation vs ParticipantFlow
• Privacy Policy
• End User Agreement — this app uses Atlassian's standard End User License Agreement (Bonterms Cloud Terms), applied automatically through the Atlassian Marketplace listing. No separate agreement is required.

08 Support

Use the ASUNOKI support page or email support@asunoki.jp. Both are private channels.