A request comes in and a whole team needs to follow it: finance on every invoice question, facilities on every move request. In Jira Service Management that is more awkward than it should be, because request participants are individual people. There is no field for a group. Here is 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 and has not been built.
Option 1: organizations
- 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, but it does not 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 somebody has to keep both lists in step.
Option 2: Jira Automation
A 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.
That 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 inside the rule and someone updates it when people join or leave. Requests that are already open do not change when the list does. And every rule run counts towards your site's monthly Automation usage, which is limited by plan.
If you are comfortable with the REST API, there is a more flexible route: the service desk API can add participants to a request with one call listing several account IDs, and you can read a group's members with the group/member endpoint. Wire that into a scheduled rule or a script and you get something close to group behaviour. It is also more moving parts to maintain, and it won't remove leavers unless you write that part too.
Prefer a script? There's a free MIT one here: https://github.com/kayabyte-2/atlassian-admin-scripts#jsm-group-participants
Option 3: ask the requester
Requesters can add participants from the portal. Fine for one-off requests, unreliable for "this team must always be on it".
Decide these before you automate anything
- Which requests? Usually a few request types per 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? Come off open requests, or stay until it is closed?
Option 4: an app that works from Jira groups
Full disclosure: we build Group Participants, so take this one with that in mind. Group Participants for Jira Service Management 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 Forge app, so it does not use your Automation rule runs.
Other Marketplace apps do the same thing, some of them cheaper. I compared a few here: https://kayabyte.dev/atlassian/guides/jsm-group-request-participants-apps-compared
For a fixed team and a couple of request types, an Automation rule is probably all you need. Once the team changes regularly, keeping a hand-written list current is the part that starts to hurt.
Jira Service Management, Jira and Atlassian are trademarks of Atlassian. Kayabyte is independent and not affiliated with or endorsed by Atlassian.
Top comments (0)