Watcher vs Participant

Laney Balis August 28, 2017

What is the difference between a participant and a watcher on a JIRA ticket?

5 answers

3 votes
Maitrey Patel
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
March 7, 2019

One issue I want to add here:

When you add an agent to the participant's list, the agent will only receive notifications as a customer receives. Even though you have added agent as water list as well.

As per the Atlassian, this functionality is as developed. 

Like if you agree and acknowledge the same.

Charlie Misonne
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
July 14, 2020

Yes and this behavior is very annoying. Especially because our users often put agents in CC of their emails to Jira.

We used scriptrunner to remove any agent from the participants list upon creation/ commenting of issues.

Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
July 14, 2020

You know they get added back when the issue is re-indexed?

2 votes
Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
August 28, 2017

A participant is someone who has contributed, or been named by an agent.

A watcher is someone tagged into an issue.  They don't have to have contributed, they can watch it themselves and anyone with "manage watchers" can add people.

Paul Stallworth
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
May 11, 2018

Hi Nic,

Thanks for the answer.  Can you help me fill in more details regarding the type of account each can/should have?

It seems to me that to be a Watcher, you must have Browse Projects permission.  However, to be a Request Participant, you don't need that permission, you just need to be in the Service Desk customer list.

Thus, it is possible to add a customer as a Request Participant to a Service Desk issue successfully, but that same customer could fail to be added as a Watcher.

Do I have that straight?  We've recently spawn more Service Desks and have run into this recently.

Tanya Botta October 2, 2018

A Watcher is someone that will be given permissions for the Jira project.  This generally isn't a customer since they wouldn't have access to your Jira system but only the Service Desk portal. 

A Requested Participant is someone being given permissions for the Jira Service Desk portal.  A customer can be added as a Requested Participant by using the "Share" function in the portal.  There are restrictions on if/who customers can share with based upon the settings you chose in the Jira Service Desk project.  Their access to view/participate would be through the portal only.

Hopefully this makes sense. 

Like # people like this
barronkid November 11, 2018

So, if I understand this correctly, if I want to add someone on my service desk team to a ticket, I should make her/him a "watcher".  Doing this seems to be something like adding the user as a BCC to the ticket correspondence; it delivers her/him the notifications, but will not display this ticket in the "watcher's" Service Desk "My Requests" area. 

If this is correct, I like this distinction.  Why?

Distinguishing participants from watchers is an approach that assists at least two ways:

  1. It involves team members by creating awareness of the issue without also exposing them to direct communication from the end customer. 
  2. When our internal team members use the service desk to raise/share requests of their own, they become reporters/participants, differentiating the user's role (on this one ticket) as an end user/customer.  In cases where they are watchers, it is clear our team members are part of the internal group working to bring resolution to the issue. 

Visibility Distinctions

  • Reporters/Participants:  The tickets will appear in the user's own service desk (and, of course, because this person is duly authorized, will also appear in the main JIRA interface). 
  • On the other hand, tickets being 'watched' will appear to this user ONLY in work-related JIRA dashboards and project issue lists.

Am I understanding, or have I missed some other important distinction/benefit/consideration?

Like # people like this
bdavies July 30, 2019

I thought this was well structured and useful but I didn't see a confirmation on this. Did you ever get confirmation that these visibility distinctions are accurate?

Like Eaton, Marguerite likes this
Confluence Bot July 31, 2019

It depends upon if you want interaction to be coming from the Portal only.  For security/confidentiality reasons some teams choose to block access from within Jira so that you can truly have Internal Comments and data hidden.  Watcher fields are only for within Jira.  Reporter and Participants are for within the Portal.  Keep in mind you can only @mention the Reporter and anyone that has access from within Jira but not Participants.  This has always been a limitation that bugs me a little.

Like # people like this
John Olah September 4, 2019

In terms of notifications sent to a participant or a watcher, my experimentation leads to the finding that you do not want the same person to be both a participant and a watcher.  To do so will block the notifications that either one sees.  And if you have someone as a watcher and an assignee, the assignee notifications do not get sent to the assignee.  As mentioned above, you cannot use the "@mention" for a participant; it only works for watchers.

 

My conclusion is to not use watchers at all, and to only use participants because of communications that are blocked.  And, don't use the "@mention" since it does not work for a participant (it only works for watchers, and since we don't use watchers...)

 

And what about "internal comments" vs regular comments when it comes to notifications sent to participants and watchers?

 

It would be nice if someone from Atlassian created a table to describe the communications based on your role when it comes to participants and watchers.  

Like # people like this
Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
September 18, 2019

This does not sound right to me, and is totally different from my experience  Participants, watchers and @ mentions all stamp a list of accounts on to an issue.

Your assessment of "don't be a participant and a watcher" is definitely incorrect.  When an event triggers a notification, Jira looks at all the users on the issue and builds a (de-duplicated) list.  If you're a watcher and a participant and the notification scheme says to tell both sets of people, you go on the list, but only once.  Doesn't matter which one was first, it's just a list of people.  Then it mails the list.  If you're included in an @ comment, it's a bit different on why it tries to add you, but it's still just a name on the recipient list.

There's very little to document here - if you match one or more rules for "getting this notification", you get it, there's no "blocking" (other than the "do not mail me on my own changes" which just removes your entry from the recipient list if it was you triggering the mail)

Internal comments only go to Jira users.  External comments go to Jira users and the customers.

Like # people like this
0 votes
Erik Hobæk March 9, 2019

But if i have Jira users that i add as partisipants, and i comment on a issue, they wont get an email notification as they are not watching the issue??

Is there a way for me to change something so that Jira users get warnings on comments even if they are not Watching a issue, but only request partisipant?

Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
March 9, 2019

You can't add participants - the field is calculated from the list of commenters, the reporter and assignee.  But you can use that field in the notification scheme to mail them all.

Like Sebastián Delmastro likes this
Paul Stallworth
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
March 11, 2019

Hi Erik,

Customer notifications for Jira Service Desk are separate from the standard Jira notifications.  JSD customer nofications are found in the "Customer notifications" tab, distinct from the Notifications tab that comes with Jira Core.  Check in both places to see who is configured to receive notifications in a JSD project.

It is possible if you add someone as a request participant (e.g. by Sharing it with them, or via the API), that they may not initially receive notifications you were expecting based upon the above mentioned settings.

Like Serge M likes this
0 votes
Dean Balani February 27, 2019

I just recently came across this question while looking for an answer for something I am trying to figure out,

We have multiple stakeholders/product owners who owns individual products. We provide support to their clients on their behalf.  How do we provide view-only access to the stakeholders/product owners to the tickets raised by customers for their product? They are not contributing just watching and may need to run some reports later i.e. how many customers we served in a month for product A.?

Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
February 28, 2019

Watchers and participants don't have anything to do with this.  You just need to make sure the project's permission scheme grants those people "browse project" (and ideally nothing else)

Like Sebastián Delmastro likes this
Dean Balani February 28, 2019

Thanks Nic. Does it mean, I will need to buy a team agent license for each one of them for view-only access?

Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
March 3, 2019

Yes, they need a licence to use Jira

0 votes
Angela Boston
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
November 2, 2018

I have a follow-up question to this, if I may.

What are the differences in triggered notifications between being a Participant and being a Watcher? 

Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
November 2, 2018

Nothing.  The emails are the same for all recipients.

Like # people like this
Angela Boston
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
November 2, 2018

Ok.  Thanks, Nic.

Suggest an answer

Log in or Sign up to answer