Add a group as request participants in Jira Service Management

By Kayabyte · Updated 1 November 2026

Short answer: Not with Jira Service Management alone: the Request participants field holds individual people, not Jira groups, and Atlassian’s request for group participants (JSDCLOUD-1268) hasn’t been built. Organizations make a request visible to their members without making them participants, and Automation can add a fixed list of people. Group Participants for Jira Service Management adds everyone in chosen Jira groups as participants and adds people who join a group to matching open requests.

A request comes in, and a whole team needs to follow it: the finance team on every invoice question, the facilities team on every move request. In Jira Service Management, request participants are individual people, and there is no field for a group. This guide shows what you can do with the built-in options and where each one stops.

How request participants work

Request participants is a field on service requests. Everyone in it gets the request’s customer notifications and can see and comment on it in the portal.
It holds people, not groups. Adding a group means adding each member by hand.
Only people who may raise requests in that service project can be participants. On sites where customers need explicit access, group members without it are rejected.

Atlassian’s request for group participants, JSDCLOUD-1268, has collected hundreds of votes over the years without being built.

Option 1: organizations

Organizations are Jira Service Management’s way of grouping customers.

In the service project, go to Customers and create an organization, or use an existing one.
Add the people to it.
Customers in the organization can share requests with it, and agents can share a request with an organization.

The catch: sharing with an organization makes the request visible to its members. It doesn’t make them participants: members get one “Organization added” email, and later updates only if they turn notifications on for that request. Organizations are also separate from Jira groups, so someone has to keep both lists in step.

Option 2: Jira Automation

An automation rule can set the Request participants field when a request is created.

Trigger: Work item created, with a condition on the request type.
Action: Edit work item and set Request participants to the people who should follow it.

This works for a fixed list of people. Automation has no simple built-in way to turn a Jira group into its current members, so the list lives in the rule and has to be updated by hand when people join or leave the team. Requests that are already open don’t change when the list does. Each rule run also counts towards your site’s monthly Automation usage, which is limited by plan.

Prefer a script? atlassian-admin-scripts has a jsm-group-participants script that adds a group’s current members as participants on one request or on the requests matching a JQL query. It’s free, MIT-licensed and uses the public REST API. It runs once, so re-run it when people join.

Option 3: ask the requester to add people

Requesters can add participants themselves from the portal. That’s fine for one-off requests and unreliable for “this team must always be on it”.

What to decide before you automate it

Which requests? Usually a few request types per service project, not everything.
New requests only, or open ones too? When someone joins the team, should they be added to requests that are already open?
What about leavers? Should people who leave the group come off the open requests, or stay on until the request is closed?

Group Participants for Jira Service Management

Group Participants is the app I make for this. It works with the Jira groups you already have.

Rules per service project and request type: new requests get everyone in the chosen groups as participants.
An agent action adds any group to a request from the work item’s actions menu.
An hourly sync adds people who join a group to matching open requests; removing people who leave is optional, and someone still covered by another rule stays on.
It stores only its settings and member snapshots, and makes no calls outside Atlassian.
It runs as its own app, so it doesn’t use your Automation rule runs.

It’s on the Atlassian Marketplace. For the CC question, see CC a whole team on every Jira Service Management request.

Other Marketplace apps also add participants from a group, some of them cheaper; see Group request participants apps for Jira Service Management compared.

FAQ

Can I pick a Jira group in the Request participants field? No. It holds people, so adding a group means adding each member.

Is sharing a request with an organization the same as adding participants? No. Organization members can see the request, get one “Organization added” email, and get later updates only if they turn notifications on for that request. See Organizations vs request participants.

Can Jira Automation add a group’s members as participants? Automation has no simple built-in way to turn a Jira group into its current members, so the rule holds a fixed list of people that has to be updated by hand when the team changes.

Does Group Participants use Jira Automation runs? No. It runs as its own Forge app, so it doesn’t count towards your Automation usage.

Who can be a request participant? Only people who may raise requests in that service project. On sites where customers need explicit access, group members without it are rejected.

Jira Service Management, Jira and Atlassian are trademarks of Atlassian. Kayabyte is an independent developer and is not affiliated with or endorsed by Atlassian.