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.
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.
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:
Am I understanding, or have I missed some other important distinction/benefit/consideration?
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.
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.
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.
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.?
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.
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?
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.
Learn how to use two new reports for next-gen projects in Jira Cloud: Cumulative flow diagram and Sprint burndown chart. Ivan Teong, Product Manager, Jira Software, demos the Cumulative ...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events