Jira Service Management: keeping request participants in sync with a group (joiners and leavers)

Adding a team to a request once is the easy part. The part that bites is next quarter: somebody joins finance, somebody leaves, and the requests already open still show last quarter's team. This is about keeping request participants in step with a group over time, and what Jira Service Management gives you for it. (If you only need the one-off "add a team to new requests" setup, I covered that in this article.)

Participants and organizations are different things

• Request participants are people on one request. They get its notifications and can comment in the portal. There is no field for a group, so a team of 12 is 12 entries.
• Organizations are lists of customers kept in Jira Service Management. Sharing a request with one makes it visible to the members. They get one "Organization added" email, and later updates only if they turn notifications on for that request.
• Neither is a Jira group. An organization is a second list that has to be maintained next to the group you already have.

So for "this team follows these requests, and the team changes", participants are the right field and organizations are not a substitute.

What happens when group membership changes

Nothing, natively. Jira groups and request participants are not linked. Add someone to a group and no existing request gains a participant. Remove someone and they stay on every request they were already on. Whatever you build has to do the syncing itself.

Option 1: Automation

A rule on Work item created, with a request type condition, can set the Request participants field. Depending on your Automation version you will find this under Edit work item, or as a dedicated action for request participants. Check what your site offers, since I have not confirmed the exact action name on every plan.

Limits for the joiners and leavers problem:

• A rule has no built-in "members of this group" list. The people are typed into the rule, so every team change means editing it.
• It runs on creation. Requests that are already open are not touched when you edit the rule.
• You can add a second rule on a schedule that searches open requests and edits each one. That works, but you have to write the add part, the remove part, and the people list yourself.
• Smart values give you the reporter and the fields on the request. I would not rely on them to expand a group into accounts. Test that on a throwaway request before building on it.
• Every run counts towards your plan's Automation usage.

Option 2: the REST API

This is the flexible route, and the pieces are small:

1. Read the group: GET /rest/api/3/group/member?groupId=...&includeInactiveUsers=false, paged.
2. Find open requests: JQL such as project = SD AND statusCategory != Done AND "Request Type" in ("Invoice question").
3. Read current participants: GET /rest/servicedeskapi/request/{issueIdOrKey}/participant.
4. Add the missing ones: POST /rest/servicedeskapi/request/{issueIdOrKey}/participant with a body of {"accountIds": [...]}.
5. Remove leavers: DELETE on the same path with the same body shape.

Things that will trip you up:

• One person who cannot be a participant (no customer access to that service project, for example) can make the whole POST fail with a 400. Retry the batch one account at a time.
• Rate limits happen on long runs. Honour Retry-After and make the job safe to run again.
• To find joiners and leavers you must keep the last-seen member list somewhere and compare it with the current one. Without that you cannot tell a leaver from someone who was added by hand.
• Decide about leavers on purpose. A person removed from the group might also have been added to a request manually, and a blanket cleanup would drop them.
• Someone may be covered by two rules for the same request type. Removing them because they left one group would be wrong.

It is a perfectly good small script, and it needs somewhere to run and be maintained.

Option 3: an app that does the sync

Full disclosure: we build Group Participants, so weigh this accordingly. Group Participants for Jira Service Management is the script above, packaged as a Forge app. From what it does today:

• Rules per service project and request type, each pointing at one or more Jira groups. New matching requests get the groups' active members as participants.
• An hourly sync looks at open requests (not in a Done status category) that match a rule and adds people who joined the group since the last run.
• Removing people who left is opt-in, because they may have been added by hand. Someone who left one rule's groups but is still covered by another rule for that request type stays on.
• A "Sync open requests now" button runs it on demand, and a manual run re-adds every current member.
• If a lookup fails or is rate limited, the rule keeps its old snapshot, so the next run tries the same joiners and leavers again. It does not treat a failed group lookup as an empty group.
• People JSM will not accept as participants are counted as "could not be added", and one such person does not fail the whole batch.
• A rule covers up to 1,000 open requests per run.
• An agent can also add any group to a single request from the work item's actions menu.
• It works with Jira groups, not organizations, and it does not cover portal-only customers, because JSM does not allow them in groups.
• It stores only its settings and member snapshots, makes no calls outside Atlassian, and runs as its own Forge app, so it does not use your Automation runs.

If your team rarely changes, an Automation rule is enough. If it changes every month and open requests matter, either write the scheduled script with the checks above or use an app. The thing to avoid is a hand-edited list that nobody owns.

For the difference between organizations and participants in more depth, see this guide.

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