Kayabyte

Stop agents or the reporter ending up as request participants

By Kayabyte · Updated 5 November 2026

Short answer: Jira Service Management has no setting I could find that keeps a person out of Request participants when a customer copies them on an email. The usual fix is an Automation rule: trigger on Field value changed for Request participants, then remove the person with { "update": { "Request participants": [ { "remove": { "id": "ACCOUNT_ID" } } ] } }. For agents who should follow a request, use Watchers instead.

Disclosure: I make Group Participants, a Jira Service Management app. It adds people as participants and doesn’t solve this problem, so nothing here needs it. The JSON comes from Atlassian’s article on participants and Automation, and I ran the remove payload through the REST API on a test site. I haven’t run these rules end to end, and the rule designs come from admins on Community, so try them in a test project first.

Why it happens

Atlassian’s article on adding request participants says addresses in the To or CC of an email can be added as participants. So a customer who replies to everyone can add:

Watchers or participants?

Atlassian’s comparison is the quickest way to decide who belongs where:

Request participants Watchers
Usually Unlicensed customers Licensed users
Can see Public comments only Internal and public comments
Notifications Customer notifications, if enabled The space’s notification scheme

So an agent who wants to follow a request should usually be a watcher.

Rule 1: remove the reporter

  1. Trigger: Field value changed. Field: Request participants. Change type: Value added.
  2. Action: Edit work item. Open More options and paste this into Additional fields:
{
  "update": {
    "Request participants": [
      { "remove": { "id": "{{issue.reporter.accountId}}" } }
    ]
  }
}

Use update, not fields. fields replaces the whole list, as I showed in the Automation JSON guide.

Rule 2: remove known people or a shared mailbox

With a short list, add a condition and remove each account ID. A commenter on JSDCLOUD-12371 uses this approach and notes the catch: each person has to be listed in the rule.

{
  "update": {
    "Request participants": [
      { "remove": { "id": "ACCOUNT_ID_1" } },
      { "remove": { "id": "ACCOUNT_ID_2" } }
    ]
  }
}

Atlassian’s article says the field takes account IDs, not email addresses. Without an account ID, you have to look the address up first with the user search API.

Rule 3: remove anyone in the agents group

This needs a web request for each participant, so it’s more work. The Community write-up has the full steps:

  1. Trigger on Value added for Request participants.
  2. Advanced branching over {{Request participants.accountId}}.
  3. Send web request to /rest/api/2/user?accountId=…&expand=groups, waiting for the response.
  4. A condition on the response: is the person in your agents group?
  5. Edit work item to remove them.

Two warnings. A commenter on that post points out that branches run at the same time, so two agents added at once can overlap. And the call needs an API token, which then sits in your rule and runs as that user.

Things to check

FAQ

Can I stop JSM adding CC’d people as participants? I found no setting that does it selectively. The usual answer is a rule that removes people afterwards.

How do I remove the reporter from request participants? Trigger on Value added, then Edit work item with remove and {{issue.reporter.accountId}}.

Should agents be participants or watchers? Usually watchers. Atlassian’s comparison says participants see public comments only, and watchers see internal comments too.

Can Automation remove a participant by email address? Not directly. The field takes account IDs, so look the address up first.

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