CC a whole team on every Jira Service Management request

By Kayabyte · Updated 1 November 2026

Short answer: Jira Service Management has no CC field for a group. The nearest things are request participants (people on one request), CC addresses on email requests, and organizations (customers who can see a shared request), and each one needs people added one by one or request by request. Group Participants adds the members of chosen Jira groups as participants on every new request, per request type, and keeps open requests in step as people join the group.

A common ask: “Whenever a customer opens a request, our account team (or our on-call team) should be copied.” In email that’s a CC. In Jira Service Management the pieces are different, and it helps to know which one matches what you want.

Three things that look like CC

Request participants. People on one request who can view it, comment and get the same notifications as the reporter. Agents add them under People → Request participants, customers with Share in the portal. Each person added gets an email saying so, and a participant can turn their notifications off. A participant is one person: there is no field for a Jira group (JSDCLOUD-1268 asks for it).

CC on email requests. When customers (or agents) CC addresses on an email sent to the project’s email channel, those people can be added as participants. That’s real CC behaviour, but it’s per email and it only covers the addresses somebody typed. It knows nothing about a Jira group, and it doesn’t help for requests raised in the portal.

Organizations. A named group of customers. A request shared with an organization is visible to its members in the portal, but they get one “Organization added” email and later updates only if they turn notifications on for that request. Organizations are for who can see requests, and they hold customers rather than your internal team. See JSM organizations vs request participants.

What you can do without an app

Automation: a rule on “work item created” can add participants, but you have to name the people. Where the rule has no group option, a list of people means maintaining the list by hand. Add a group as request participants in Jira Service Management goes through this and the REST route.
Notification scheme or a shared mailbox: to inform an internal team, a forwarding rule on a mailbox or a Slack-style notification works, but those people aren’t participants on the request.
Manual add per request: fine for a few requests a week.

The gap in all of these is the same: a change in the team (someone joins or leaves) means editing every rule or list.

Using a Jira group with Group Participants

Group Participants is the Jira Service Management app I make for this. How it behaves:

Rules per request type: a rule picks request types (or leaves them empty to cover every type in the project) and one or more Jira groups. Different request types can copy different teams.
On a new request: the app reads the active members of the rule’s groups and adds them as participants, usually within a few seconds. The reporter and people already on the request are skipped.
Joiners: every hour it adds people who joined a group to the rule’s open requests (status not in the Done category). Requests that are already done are left alone.
Leavers: removal is off by default, because someone may also have been added by hand. Switch it on to remove people who left a group from open requests.
Existing requests: Sync open requests now brings open requests in line, up to 1,000 per rule per sync.
By hand: on any request, Actions → Add group as participants, using the agent’s own permissions.
Limits: only active Atlassian accounts are added. Jira Service Management decides who can be a participant, so people without customer access to the project are rejected, and portal-only customers can’t be in Jira groups.
Where it runs: on Atlassian (Forge); it makes no calls outside Atlassian.

It’s on the Atlassian Marketplace. To compare it with other apps for the same job, see Group request participants apps for Jira Service Management compared.

Which one should you use?

You want a team to follow every request of a type: participants from a group.
You want customers from one company to see each other’s requests: an organization.
Customers who email in and CC a colleague: that already works through the email channel.

FAQ

Can I CC a Jira group on every Jira Service Management request? Not natively. There’s no group CC field, so you add people as request participants one by one, or use an app that adds a group’s members.

Do participants get the same emails as the reporter? Yes, they get the same notifications as the reporter, and each participant can turn them off.

Do organization members get every update? No. They get one “Organization added” email when a request is shared with their organization, and later updates only if they turn notifications on.

Does Group Participants add people who join the group later? Yes, to matching open requests, on the hourly check. It removes people who left only if you switch that on.

Can Group Participants add portal-only customers? No. Jira doesn’t allow portal-only customers in Jira groups, so it can only add people with an Atlassian account on your site.

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

CC a whole team on every Jira Service Management request

Three things that look like CC

What you can do without an app

Using a Jira group with Group Participants

Which one should you use?

FAQ

More guides