In tickets and requested items when posting to additional comments, a mail is generated to the user with this content. Conversely when they reply, the reply is put into additional comments. This is fine.
Sometimes the Servicedesk needs to contact someone else by email though. If it's a colleague they will use the @ function and write in work notes. If it's an external provider or another end-user they will use the Email function:
Now here's the issue. When the external provider answers the e-mail sent from the ticket, the answer is automatically inserted into additional comments and thereby is viewable on the service portal as well as sent in an Email to the user. this is very undesirable as the info from Microsoft, Cisco etc. is not always something the user should be privy to. As well as it pretty much being spam if there is a long dialogue between technicians before the issue is resolved. The users don't need to know how the sausage is made so to speak.
So my question: Where do I change the mails sent to a ticket to be logged in work notes in stead of additional comments? Since it's not default, are there any drawbacks to changing this?
Thanks in advance for any replies.
Work notes being visible on the portal by the end user is an ACL issue.
I would look to see if you have an ACL, similar to what is in place for comments, for the field work_notes that allows the caller to see it. This is what exists for comments out of box as an example:
You'll likely see one with work_notes. You can always add the "updated by" column when viewing ACLs to see the records that someone manually created, as work notes are locked by default so this is something someone in your instance did.
Notifications being sent to the end user for work note updates is a notification issue.
You likely have had a requirement in the past that changed the ACL (above) so that a notification could be sent out. I would start by looking for notifications that are firing for the event incident.worknoted or incident.worknotelist. Then open each of these up to investigate. Those are the out of box events and it's likely someone piggybacked off of them:
You're looking for the caller (or whoever you log the incident against) to be in the Who will receive form section of the notification. Similar to this (except for the caller):
If you have an example of a client receiving the email you can open up the email logs, open up that email, and see exactly what notification it was:
I just want to explain all the pieces individually so it makes sense together. But going through the email logs will narrow it down to you immediately.
Any help let me know!
Thank you so much for explaining how everything is connected.
This is where I'm at now:
When (being a third party) replying to a mail sent from the incident, the notification the end user receives is via the notification incident commented internally which is set up like this:
So it will be executed when work notes is updated by someone who is not the one the ticket is assigned to. In other words, a third party replying to a user ticket.
And who will receive is the person the ticket is assigned to:
So yeah.... it actually worked just after making the changes suggested by Espinar. Stupid me hadn't considered that the reason the user (me) got the "ticket updated" mail was because... I was also the assigned to. I just made the same test with the ticket not assigned to anyone. It worked perfectly. The reply from the third party was not visible on the portal by me and no "ticket updated" mail was sent.
Trevor, thank you so much for explaining everything. Even though I did not need to change anything I definetely learned something which will make other alterations much easier in the future.
And Espinar, thank you for a quick solution, it worked perfectly.
This is a great forum.
