Request Participants are useful when people besides the reporter need access to a Jira Service Management request. Depending on the project’s permissions and notification configuration, participants can view the request, add public comments, and receive relevant customer notifications.
Managing participants on one request is straightforward. The administrative problem becomes more interesting when you need to make similar participant changes across many requests.
There are several ways to handle this in Jira Service Management Cloud. The right approach depends on whether the task is small, rule-driven, integrated with another system, or an ad hoc bulk administration job.
Need — Best fit
A few requests — Manual editing
A predictable condition — Jira Automation
External integration or custom logic — REST API
A selected batch where you want to review changes before applying them — Bulk Participants for JSM
Option 1: Update requests individually
For a small number of requests, the simplest approach is usually direct editing.
An agent can open a request and update its Request Participants. Customers may also be able to share requests through the help center, depending on the service project’s sharing permissions.
This approach works well when:
• only a few requests need changing
• you know which requests need changing
• the task is uncommon
• reviewing each request is useful
There is little reason to introduce automation or custom tooling when the job is genuinely small.
Option 2: Use Jira Automation for repeatable rules
Automation becomes more useful when the participant change follows a predictable condition.
For example, an automation rule can add or remove known accounts from the Request Participants field, or derive participants from information already available to the rule. Atlassian also documents approaches that use the Jira Service Management REST API through a Send web request action.
Automation is a strong choice when the logic can be expressed as something like:
• when a request is created, add a particular participant
• when a field changes, add or remove participants
• when a request matches defined conditions, update its participant list
• copy appropriate users from another field
The important distinction is that Automation works best when the rule itself can determine what should happen.
If an administrator repeatedly needs to make one-off decisions about different sets of existing requests, creating and maintaining a rule for each situation may be more work than the change itself.
Automation or an API-based integration may also be preferable when participant membership needs to stay continuously synchronized with another system or source of truth.
Option 3: Use the Jira Service Management REST API
For teams comfortable with scripting or integrations, the Jira Service Management REST API provides request-level operations for working with Request Participants.
It can be used to:
• retrieve the participants on a request
• add Request Participants
• remove Request Participants
This makes the API a strong foundation when participant management is part of a larger internal workflow, migration, integration, or administrative script.
The tradeoff is operational overhead.
A custom implementation needs to handle authentication, permissions, account identifiers, request selection, errors, partial failures, and whatever recovery or reporting the workflow requires.
For a recurring engineering workflow, that may be entirely appropriate.
For an administrator who simply needs to safely update a selected batch of requests, it can be more infrastructure than the task warrants.
Option 4: Use a purpose-built bulk workflow for ad hoc administration
“I have a specific set of JSM requests, and I need to change their Request Participants safely right now.”
That was the problem that led me to build Bulk Participants for JSM. Disclosure up front: I’m the developer of the app.
The workflow is most useful when the relevant participant relationships already exist in the requests being worked with. The app does not search a global customer directory or provision new customers.
Bulk Participants for JSM is designed for Jira Service Management Cloud administrators who need to select requests using JQL or pasted issue keys and then Add, Remove, or Replace Request Participants across a batch.
Each batch operates within one Jira Service Management service desk.
Before anything is changed, the workflow requires a Preview before Apply. Replace operations also include stale-state protection so that a request that changed after the preview is not blindly overwritten.
After an operation, results are reported per request, and recent operation history is available for reviewing previous bulk actions.
One example would be a team transition where several existing requests need their participant assignments cleaned up or changed consistently. Another might be incident follow-up where an administrator has identified a specific set of requests and needs to update existing participant relationships across that set.
There is an important boundary to the app’s scope.
Its participant choices come from Request Participants already present on the selected requests. It does not:
• create arbitrary customers
• provide a global customer or user directory
• manage Organizations
• manage watchers
• perform general Jira user administration
• edit unrelated Jira fields
• continuously synchronize participants with another system
That makes it a fit when the relevant participant relationships already exist in the requests you are working with and you need a controlled way to reuse or change them across a selected batch.
If that matches your use case, Bulk Participants for JSM is available on the Atlassian Marketplace: Bulk Participants for JSM
Choose based on the shape of the task
For a handful of requests, edit them directly.
For a predictable business rule, start with Jira Automation.
For an integration, continuous synchronization requirement, or custom workflow, use the Jira Service Management REST API.
For an ad hoc administrative change across a selected batch of requests, especially when reviewing the intended changes before applying them matters, a dedicated bulk workflow may make more sense.
These approaches do not have to replace one another.
A JSM environment might use direct editing for exceptions, Automation for predictable behavior, APIs for integrations, and a bulk administration tool for occasional multi-request changes.
The key question is:
Is this a one-request task, a repeatable rule, an integration, or a one-off multi-request administrative change?
Once that is clear, the implementation choice usually becomes much easier.
