A load test on our own development site added 4 people to 485 open Jira Service Management requests. That's 1,940 adds, and about 700 emails reached one inbox within a short time. Here is what caused it and how to avoid it.

What sends the email

Participant added is one of the customer notifications of each service project, and it's on by default. It emails a person each time they are added to a request, so bulk adds multiply: 5 people on 200 open requests can mean up to 1,000 emails. In our test an app made the adds and the emails still came from Jira's notification.

Treat people times requests as an upper limit, not a forecast. 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

  1. Open the service project and go to Space settings (called project settings on some sites).
  2. Go to Notifications → Customer notifications.
  3. Turn off Participant added. You need to be an admin of that project.
  4. Run the bulk add.
  5. 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

  • Limit the add to the request types that need the team.
  • Close stale requests first. Old open requests are often most of the count.
  • Add the team to new requests from now on, and leave open ones alone unless someone needs them.
  • 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.

Disclosure

The test was of Group Participants, a Jira Service Management app I make that adds whole Jira groups as participants. It can't silence Jira's email either. After this test, a sync shows the most emails Jira can send before it starts, hourly adds to open requests are off by default, and a rule with more than 25 open requests waits for you. It has no reviews yet.

The full guide is on kayabyte.dev.