Disclosure up front: I work on User Access Review for Jira (Permissions & Audit) at Ballon Apps, an Atlassian Marketplace partner — so weigh the app mention at the end accordingly.
On the sync question itself: I don't think a native way to keep Request Participants continuously in step with a group exists today, and two details are worth knowing before you build around it.
There is no "user added to group" trigger in Jira automation. That trigger exists in Confluence automation only; the request to bring it to Jira is AUTO-1757, still at Gathering Interest since March 2025. So on the Jira side there's no membership event to react to at all (and the Confluence one has open bugs about not firing / not returning the user, so I wouldn't lean on it even where it does exist).
What Atlassian does document is the KB article "How to add group members as request participants": a rule that resolves the group with two Send web request calls against the group member REST endpoint, then writes the accountIds into the field. It states plainly that it adds the members at the time the rule runs, and that later group changes are not synced back to existing requests — so it's a point-in-time fill, not a sync. Large groups can also hit automation execution limits. Native group support in the field is JSDCLOUD-1268 (~366 votes, Gathering Interest); Atlassian's other pointer is that native groups mostly relocate the membership you have to keep in step from a Jira group to an org.
The drift half of your question is the part I've actually spent time on, from a different angle — we look at project roles and permission-scheme grants, not Request Participants. The lesson that transferred is that nothing in Jira flags the divergence; you only see it if you go and look. The nastiest case we hit read as "2 apps, 0 people" on a project when we checked role membership, while the permission scheme was granting Browse Projects to the application role — i.e. every licensed user. The check wasn't wrong about roles, it just wasn't looking at the layer the access actually came from.
What worked for us wasn't syncing but dated snapshots plus a diff, so a change surfaces as a dated delta instead of a silent state. Being straight about the limit: our snapshots record a group grant as the group and deliberately don't expand its members, so our own diffs would not catch someone joining or leaving a group — exactly the change you care about. So this is a pattern that might transfer, not a tool that solves your case.
Which makes me curious about your actual requirement: would periodic snapshot-and-diff be enough, or do the participants have to be right at the moment the request is raised? If it's the latter, the point-in-time fill on creation plus a periodic reconciliation pass over open requests is probably as close as you get today.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.