Watcher vs Participant

[Laney Balis]

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

[Maitrey Patel]

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]

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-]

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

[Nic Brough -Adaptavist-]

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]

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]

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. 

[barronkid]

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?

[bdavies]

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?

[Confluence Bot]

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.

[John Olah]

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.  

[Nic Brough -Adaptavist-]

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.

[Erik Hobæk]

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-]

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.

[Paul Stallworth]

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.

[Dean Balani]

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-]

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)

[Dean Balani]

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-]

Yes, they need a licence to use Jira

[Angela Boston]

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-]

Nothing.  The emails are the same for all recipients.

[Angela Boston]

Ok.  Thanks, Nic.