A common ask from support leads: "Whenever a customer opens a ticket, our account team should be copied." In email that is a CC. In Jira Service Management there is no CC field for a group, and the pieces that look like one behave differently. Here is what each does, and where the gaps are.
Request participants
Participants are people added to one request. They can view it, comment and get the same notifications as the reporter. Agents add them under People, then Request participants. Customers can do it with Share in the portal. Each person added gets an email saying so, and a participant can turn their notifications off.
The catch: a participant is one person. There is no field for a Jira group (JSDCLOUD-1268 on jira.atlassian.com asks for it), so a team of 8 is 8 entries on every request.
CC on email requests
If customers CC addresses on an email to the project's email channel, those people can be added as participants. That is real CC behaviour, but it is per email, it only covers addresses somebody typed, and it knows nothing about your groups. It does nothing for requests raised in the portal.
Organizations and customer notification settings
An organization is a named group of customers. A request shared with one is visible to its members in the portal. They get a single "Organization added" email, and later updates only if they turn notifications on for that request. So organizations answer "who can see this", not "who follows this", and they hold customers, not your internal team.
The project's customer notification settings decide which emails customers get for a request. They control what is sent to people who are already on it. They do not add anyone.
Automation
A rule on Work item created can set Request participants, so a fixed list of people can be added to every new request of a type. Depending on your Automation version this is under Edit work item or a dedicated participants action, so check what your site offers.
The limit is the one you would expect: the people are typed into the rule. When someone joins or leaves the team you edit the rule, and requests that are already open do not change. Each run also counts towards your plan's Automation usage.
When a native setup is enough
If the team is small and rarely changes, one Automation rule per request type is fine. If you only need a handful of requests followed, adding participants by hand is fine too. Neither stops being fiddly when the team changes every month.
The app route
Full disclosure: we build Group Participants, so weigh this accordingly. Group Participants for Jira Service Management uses Jira groups instead of typed lists. From what it does today:
- Rules per service project and request type (or every type if you leave it empty), each pointing at one or more Jira groups.
- On a new request it adds the active members of those groups as participants, usually within a few seconds. The reporter and people already on the request are skipped.
- An hourly check adds people who joined the group to matching open requests (not in a Done status category).
- Removing people who left is off by default, because someone may also have been added by hand. You can switch it on.
- "Sync open requests now" brings existing open requests in line, up to 1,000 per rule per run.
- On any request, Actions then Add group as participants does the same for one request, using the agent's own permissions.
- Limits: only active Atlassian accounts are added, and Jira Service Management decides who can be a participant, so people without customer access to the project are rejected. Portal-only customers cannot be in Jira groups, so they are not covered. It works with Jira groups, not organizations.
- It runs on Atlassian (Forge) and makes no calls outside it.
Which one to use
- A team should follow every request of a type, and the team changes: participants from a group.
- Customers from one company should see each other's requests: an organization.
- Customers who email in and CC a colleague: the email channel already handles that.
The longer version, with a FAQ, is in this guide.
Jira Service Management, Jira and Atlassian are trademarks of Atlassian. Kayabyte is independent and not affiliated with or endorsed by Atlassian.
Top comments (0)