Why adding request participants in bulk floods inboxes in Jira Service Management, and how to avoid it

Q: How do I add request participants without sending emails?

Turn off Participant added under Customer notifications in the project’s settings, do the add, then turn it on again. It affects the whole project while it’s off.

By Kayabyte · Updated 4 November 2026

Short answer: Jira Service Management’s customer notification “Participant added” emails a person each time they are added to a request, so bulk adds multiply fast: 5 people on 200 open requests can mean up to 1,000 emails. The add-participant API has no option to skip it. To avoid the flood, a project admin turns off Participant added under Customer notifications before the bulk add and turns it on again afterwards, or adds people only to new requests from then on. Group Participants is the app I make for adding whole groups; it shows these numbers before a sync and holds back hourly adds above 25 open requests or 100 emails.

We learned this the hard way. A load test on our own development site added 4 people to 485 open requests, 1,940 adds in all, and about 700 emails reached one inbox within a short time. Nobody had asked for them, and each one looked like a separate piece of work to look at.

What sends the email

Jira Service Management sends it, not the tool doing the adding. In our test an app made the adds and the emails still came from Jira’s notification. Participant added is one of the customer notifications of each service project, and it’s on by default. The email says who added the person, and its subject is the request’s key and summary.

This matters in three common situations:

A script or app adds a group to all open requests.
A new person joins a team and is added to everything the team follows.
A migration or clean-up sets participants on old requests.

The worst case is people times requests. Treat that number as an upper limit, not a forecast: in our test fewer emails arrived than adds were made, and some single adds on the same site sent none at all. We don’t know why, so plan for the upper limit.

How to turn it off for a bulk add

Open the service project and go to Space settings (called project settings on some sites).
Go to Notifications → Customer notifications.
Turn off Participant added. You need to be an admin of that project.
Run the bulk add.
Turn Participant added on again.

The setting applies to the whole project while it’s off, so anyone added by an agent or a customer in that window isn’t told either. Pick a quiet time.

If you’d rather leave the setting alone, these reduce the number of emails:

Bulk add only where it’s needed. Limit the add to the request types that need the team, not all of them.
Close stale requests first. Old open requests are often most of the count.
Start with new requests. Add the team to new requests from now on, and leave the open ones alone unless someone needs them.
Test on one request. Add one person to one request and check what arrives before you run the rest.

What the API offers

The participant call (POST /rest/servicedeskapi/request/{key}/participant) has no notification option. The general edit call (PUT /rest/api/3/issue/{key}?notifyUsers=false) can skip notifications and can update the participants field, but it needs more permissions. We couldn’t confirm it stops this email, because the single requests we tried it on sent no email either way. Try it on one request with a real inbox before relying on it.

Group Participants

Group Participants is the app I make. It adds the members of chosen Jira groups as participants, and it can’t silence Jira’s email either. What it does about the numbers:

A new rule, or a rule whose groups changed, adds nobody to open requests by itself.
Sync open requests now first shows the people, the open requests and the most emails Jira can send, and waits for your confirmation.
Adding people who join a group to open requests every hour is off by default.
With that switched on, a rule with more than 25 open requests adds nobody and shows a warning on the settings page, so one new team member can’t get hundreds of emails. A check also waits if it would send more than 100 emails in all. Each person can still get up to 25 per rule.
Each rule shows how many people it adds to each new request, with a warning above 25, and the agent action shows the count before you confirm.

It’s on the Atlassian Marketplace. It has no reviews yet, and the settings above are the safeguards we added after our own test flooded an inbox.

FAQ

Why did everyone get so many emails after adding participants? Jira Service Management’s “Participant added” notification emails a person for each request they are added to. Adding a group to many requests can send up to one email per person per request.

How do I add request participants without sending emails? Turn off Participant added under Customer notifications in the project’s settings, do the add, then turn it on again. It affects the whole project while it’s off.

Can the REST API add participants silently? The participant call has no such option. The issue edit call with notifyUsers=false needs more permissions, and we couldn’t confirm that it stops this email.

Can a participant stop these emails themselves? A participant can turn off notifications for a request they are on, but that’s one request at a time and doesn’t help when they’re being added to hundreds.

Does this apply when an app adds the participants? Yes. The emails in our test came from an app’s adds, through the same notification.

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

Why adding request participants in bulk floods inboxes in Jira Service Management, and how to avoid it

What sends the email

How to turn it off for a bulk add

What the API offers

Group Participants

FAQ

More guides