JSM organizations vs request participants: which to use

By Kayabyte · Updated 1 November 2026

Short answer: Request participants are people on one request who get its notifications; organizations are groups of customers who can see requests shared with them, but after one “Organization added” email they get updates only if they turn notifications on. Use organizations for who can see requests and participants for who follows them. To keep a whole Jira group following requests, Group Participants for Jira Service Management adds the group’s members as participants.

Jira Service Management has two ways to bring more people into a request: organizations and request participants. They sound alike and they do different jobs. This guide explains what each one does, the sharing settings that control them, when to use which, and how to keep a whole team on requests.

The short version

Request participants are people on one request. They can view it, comment on it and get the same notifications as the reporter. A participant can turn those notifications off.
Organizations are groups of customers. A request shared with an organization is visible to its members in the portal. Members get one “Organization added” email when it’s shared, and later updates only if they turn notifications on for that request.

Participants are about taking part in a request. Organizations are about who can see it.

Request participants

Atlassian describes them in Add request participants:

Agents add them in the request under People → Request participants. Customers add them with Share in the portal, or by adding addresses in the To or CC field of an email.
What a customer can add depends on the project’s customer permissions.
Each person added gets an email saying so.
Participants follow the work item’s security scheme. If only the reporter can see the request, participants can’t either.

A participant is a person. There is no field for a Jira group, so a team of 12 means 12 entries. Atlassian’s request for group participants is JSDCLOUD-1268.

Organizations

An organization is a named group of customers that can be added to several service projects. A customer can be in more than one.

Sharing. Atlassian’s guide to customer organizations says members can see requests shared with their organization in the portal.
Notifications. All members get an “Organization added” notification when a request is shared. After that, they only get updates if they open the request and turn notifications on. You can switch the first email off under Project settings → Notifications → Customer notifications.
Default sharing. A site setting under Organization management, “Should new requests automatically be shared with a customer’s organization?”, decides the default. It only works when the customer is in exactly one organization.
Enforcing it. The setting only changes the default. Customers can still choose, so a rule has to enforce it. Atlassian’s article on automatic sharing uses Automation to clear the Organizations field.
Who can share. Under the project’s customer permissions, sharing can be limited to a customer’s own organizations, or opened to anyone in the project, or to people entered by email. Customers who aren’t in an organization can’t share in the most restrictive setting. See Atlassian’s share options.

Organizations are lists of customers kept in Jira Service Management. They are separate from Jira groups, so a team that already exists as a Jira group needs a second list kept in step.

Which to use

You want	Use
Everyone at a customer’s company to see its requests	Organization
Customers to share requests within their own company	Organization, with sharing set to organizations
One colleague to follow one request	Request participant
Your own internal team to follow every request of a kind	Neither, on their own (see below)
A single person to be notified of every update	Request participant

Keeping a team on requests

Say the finance team should follow every invoice request. Organizations show the request to the team but don’t keep them updated on it. Participants keep them updated but have to be added person by person.

What you can do with built-in options:

Automation. A rule on Work item created that edits Request participants for a request type. The list of people lives in the rule, so someone has to edit it when the team changes, and open requests don’t change.
Ask the reporter. Reporters can add people with Share. This is easy to forget.
Organization plus notifications. Share with the organization and let people turn on notifications per request. It works for people who remember to do it.

Group Participants for Jira Service Management

Group Participants is the app I make for this. It makes a Jira group count as participants, so the team follows the requests and not only sees them.

Rules per service project and request type: new requests get everyone in the chosen groups as participants.
An agent action adds any group to a request from the work item’s actions menu.
An hourly sync adds people who join a group to matching open requests. Removing people who leave is optional.
It works with Jira groups, not with organizations.
It stores only its settings and member snapshots, and makes no calls outside Atlassian.

It’s on the Atlassian Marketplace. For the step-by-step version, see how to add a group as request participants. Looking for a CC for a team? See CC a whole team on every Jira Service Management request.

FAQ

Do organization members get updates on shared requests? Only the first “Organization added” email, which you can switch off under Project settings → Notifications → Customer notifications. After that, only if they open the request and turn notifications on.

Can a request participant stop getting notifications? Yes. A participant can turn the request’s notifications off.

Are organizations the same as Jira groups? No. Organizations are lists of customers kept in Jira Service Management, separate from Jira groups.

Can new requests be shared with the customer’s organization automatically? A site setting decides the default, and it only works when the customer is in exactly one organization. Customers can still choose, so enforcing it takes an Automation rule.

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