215

Admins/agents can edit ticket comments

Every comment/update/request should be editable by an agent.

Need the ability to edit existing comments in the ticket thread

often typo's or other simple mistakes are made that need to be corrected

this is espcially relevant if a public comment is posted by mistake that has information that is not appropriate for the end user to see

Im sure we all run into this as good as our Agents are

Tiago Soromenho had a similar request embeded in his thread but just for the initial request

every comment/update/request should be editable by an agent

thanks 

All in all pretty happy with the interface so far!!

 

Zendesk Update, March 2015

Though an exact solution for this feature request is unavailable, we want to let you know what options are available to modify tickets:

  1. Ticket Redaction App. This app allows you to remove attachments and portions of text from tickets. 
  2. Redaction API. This allows you to permanently remove words or strings of text from a ticket comment.

232 comments

  • Official comment

    Hey everyone,

    I've been following this thread for some time now, and after reviewing with the rest of the Product team we believe it’s time to close this.

    As happens with many feature requests, not everyone in the thread has the same problem, needs or expectations over what solution will be created for the request.

    Here is what we've gathered as problems being mentioned in this thread:

    • I made a mistake and I want to change it 
    • Someone in a ticket has added their password/social security/credit card information and I need to remove it 
    • The comment I added should have been a private comment 
    • There's a bunch of noise from my/their signature or disclaimer that I want to get rid of
    • The Markdown struggle is real, I get the syntax wrong sometimes

    It's these problems I would like to spend some time diving into.

    What we've done

    While we have not been able to directly address the initial request in its original ask, we have been able to address some problems.

    If you've made the mistake of adding in a public comment when it should have been an internal note, you can easily switch it.

    You can also "redact" parts of a comment and attachments if they contain something that should no longer be saved in Zendesk. You can even have Zendesk automatically detect credit card numbers and social security numbers and redact those.

    What we will do

    At this time, we have no intention of allowing any user-type to edit their comment in the ticket stream. However, we would like to look into the following within the next 12 months:

    • Adding an "undo" for ticket saves. This will give you a few seconds before your update is actually committed thus allowing you to recover from a mistake you may have made and realized. I know this has saved me on a number of occasions in Gmail
    • Hide duplicated content or content that looks like it could be a signature. Many email clients now make a good attempt at doing this. Zendesk should be able to as well
    • Create a better way of styling outbound content that does not rely on Markdown, or you knowing the Markdown syntax

    We believe this will provide solutions to some of the other problems raised in this thread as mentioned earlier.

    Why we're not implementing this

    At this time at least, the solution being requested does not fit in with the direction and vision we have for Zendesk.

    We believe that the integrity of a ticket and its comments are important. When either party reads comments on Zendesk tickets, they should be able to trust the content is unaltered from its original context.

    We also recognize that once a comment has been saved in Zendesk, an email containing that comment has already been sent out (in the vast majority of cases). As Zendesk further matures embeddables, in app or on mobile push notifications will also contain comments - albeit likely just a snippet.

    Closing this thread and further requests

    As mentioned earlier, this thread will now be closed to further comments. I welcome further discussion around undo, redaction or content sanitation. However, we will close down further requests for the direct editing of ticket comments, either for end-users or agents.

    Thank you all,

    Jake Holman

    Director of Product

  • 0

    We've had this feedback too. To some extent we have been happy enough to treat the recording on the basis of as is/as was. The audit trail is powerful. If this could be maintained/not compromised, by supporting editing then this would remove issues that get reported.

    A similar use case is unintended public & non-public comments. We've had requests for these to be switchable.

     

     

  • 0

    I second this. The user who created the ticket should also be able to go in and modify it's priority and status as well. For big projects I typically fix a lot of bugs that I find before I notice the ticket. In my old helpdesk, I'd ask my users to periodically review and close out any tickets that they've submitted which have been fixed; now I have to do it manually. :-(

  • 0

    Would love to see this too, especially Graham's "A similar use case is unintended public & non-public comments. We've had requests for these to be switchable."

     

  • 0

    I would really worry about the audit trail.  But I would love to be able to strip out signatures when users forget to remove them before sending!

  • 0

    I also would appreciate this feature as occasionally I get comments put into the wrong tickets. As far as the audit trail goes, why not keep a log of the deleted comments and who deleted them. It could show up in the "All events and notifications" but be removed from the comments thread. So, you keep the audit-ability and keep garbage information from cluttering up the ticket.

  • 0

    this functionality exists in most wiki-based solutions and would be appropriate here.

  • 0

    I agree that this is a really important feature that should be included. Typos, private/public mistakes, not deleting the message info Outlook inserts above the delimter line... there are plenty of way to make mistakes. Not being able to correct them is a bit scary.

  • 0

    Yes, I agree that admins need to have this control, and maybe select agents, but not the end user.

    I think allowing users to edit their comments or original request could be trouble. With the power to edit comments, agents or admins could clean out signatures, etc.

  • 0

    We all make mistakes and typos once in a while and it would be great if we could go back in time and undo them. Unfortunately, this isn't and should not be possible in Zendesk.

    The event history acts as an audit trial that records every single change to a ticket; when it happened and what caused it to happen. If you ever looked through the event history, you can see each state change as well as which triggers notified users and agents. If you were able to go back in history and change comments, this audit trial would become invalid and it would be very hard to troubleshoot the system.

    Just as with email, you have to proof-read your message before you hit the send button. Once that message hits the mail server, you can't recall it.

  • 0

    I think it's fine to retain all the changes and history in the event log, however, I see no reason that you shouldn't be able to adjust what gets displayed in the thread that is visible to the end-users.

  • 0

    I agree; the audit trail and comment trail (thread) need to become separated. The agent should be able to switch between the comment trail as the user would see it and the full audit trail. Something you would see in the audit trail would be "Ticket description changed by ..." or "Comment 2 deleted by ...".

    Currently it is impossible to ever take a comment back or correct a mistake, however I think only agents would need to be able to do this.

    Even just to clean up signatures from the ticket description would be good. Sometimes emails contain huge threads inside them and it's almost better to delete the ticket and create a new one.

  • 0

    Are there any plans to include this in a future update? I would say this is the single biggest issue I have with zendesk.

  • 0

    I would also like to be able to edit comments.  If we had to proofread every time we entered a comment it would add too much extra time.  There have been times when I have proofread something several times and then look at it later see something wrong.  Even proofread mail goes out wrong.

    Zendesk seems little more than a fancy forum application, even the most basic forums allow users to edit posts AND let you know that the post/comment has been edited.

    I really like Zendesk, but I am stupid and hasty, please allow me to correct my mistakes by editing them and not blatantly showing my customers that I don't know how to speel.

    Thomas - you mention that each and every change needs to be displayed for the audit trail.  If an agent edits a comment, couldn't Zendesk just make a copy of the original, add it as a Quote to the changed comment and only display the changed comment to end users?  That way we get to make changes and the original gets to stay around for the audit trail.

    I'll again display my stupidity, but why is the audit trail so rigidly important.  If an end user doesn't trust you to not change comments honestly won't he keep an email and challenge you with discrepancies?

  • 0

    Thank you everybody who have submitted their thoughts on this subject. 

    I would like to point out a few impracticalities in allowing editing of the audit trail. 

    1) If a public message has been posted and then later been made private, what should happen to email notifications and trigger actions that has already been sent or acted on by the public comment?

    2) What if a ticket update contained a certain keyword or phrase that has fired off a number of triggers, gets updated and then fires off another set of triggers?

    3) What if one of your agents tells one of your customers to "f*** off" but then later deletes his own comment?

    The big idea about an audit trail is to maintain a record showing who said what and what operations were performed during a ticket's lifetime. And in case of disputes, audit trails can work as direct evidence. Ensuring and settling liability issues.

    So basically the audit trail is the core component of a help desk. If you don't need an uncorrupted audit trail, you probably don't need a help desk. You may want to look for a "fancy forum application" in stead :-)

    So despite the fact that I love and encourage all customer feedback, the** ability to mess with the audit trail will never happen**.

    To prevent agents posting wrong or misspelled information or unintentionally post public messages, we have considered implementing a "grace period" for ticket updates. That would give agents e.g. five minutes from posting an update to fix spelling errors and so, before the update was submitted to the ticket.

    How to deal with long mail signatures and unintentionally included mail threads is another issue that we try to deal with. We also prefer to keep the comment trail slick, to the point and free of noise.

    Thats for all the comments so far.

  • 0

    I have to tend to agree with Mikkel on the importance and integrity of the audit trail. A lot like a conversation, what was said, was said.

    I like the offered compromise of the grace period - I've seen this used in other applications to good effect. Given that mistakes are likely to be spotted after the post submit button moment, a grace period should cover most accidents. I guess that the grace period should be linked to triggers so that they don't fire until the grace period is up.

    This would also help rectify one of my common dooh momets when I select the wrong type of comment - public vs. private.

  • 0

    So, here's a big reason that there MUST be some way to edit a comment/ticket update that comes in through an email. I have on my Help Desk right now an update that went to the wrong ticket. The ticket it went to is a ticket from a totally different client. Now one of my clients is seeing a whole bunch of info relating to private network information of a different client. THIS IS TOTALLY UNACCEPTABLE. Accidents do happen. We do want to maintain the integrity of the audit trail, but there has to be the exception that proves every rule. This is that exception. I am now in an incredibly awkward position having to explain to a client why their private info is showing up in a ticket for another client and explain to that client that they should disregard all that information that just got added to their ticket regarding another client's issues and network info. THIS IS A SECURITY ISSUE!! You can provide the edit capability for the owner or admin, but not for the agents. This provides a workable solution for the rare occasion that something like this happens.

  • 0

    My partner had this to add to the discussion.  "I also would appreciate this feature as occasionally I get comments put into the wrong tickets. As far as the audit trail goes, why not keep a log of the deleted comments and who deleted them. It could show up in the 'All events and notifications' but be removed from the comments thread. So, you keep the audit-ability and keep garbage information from cluttering up the ticket."

  • 0

    No matter how many times this is explained by Zendesk support, I still can't accept that this is such a big deal to be able to hide mistakes. In the case Kevin presents, sure... an error was made and information got out. But the fact that the information will stay there in the ticket for the wrong customer for the rest of time just seems silly. Leave it in the official audit trail, just have an option to hide it from the customer. I'm not sure why you're pushing us to a not-all-that-fancy forum application to replace an otherwise good tool in Zendesk because of stubborness on this issue. If you're doing it to protect against an agent undoing a comment they're embarrased of, make it an admin-only feature. Or, make it a global option that can be turned on or off so that the site owner can decide if they want this to be available.

  • 0

    Please allow us to EDIT!!! Pretty please?  I now have a ticket that somehow took the attachment and converted it to text and it shows the entire MIME message in the ticket view.  This causes me to scroll 3 or 4 pages worth of text to get down past that one ticket.  I also have another ticket that was sent with forwarded text in the message.  That also now requires me to scroll, scroll, scroll in the working tickets view.  If I had the ability to truncate the initial message and place the relevant text in an update I would have less clutter in the working tickets view.

    Protecting us from ourselves is what governments do, not our software vendors.  Give the admins the ability not the agents.  If we're doing something that we shouldn't be doing with the audit trail, then our business will eventually fail and it won’t matter that we were deleting someone’s ticket updates, changing typos or correcting major oops factors.

    I don't look forward to the day when I screw up and post to the wrong ticket.  Then I can feel as bad as Mr. Gilbert and have no way to correct the mistake.  However I have already made plenty of typos to look like a 2nd grader who is just learning to speel.  It sure would be nice to go back and look a bit more educated than that… I would also hope that my typos are not going to cause triggers to fire, I would start to suspect that SkyNet is a bit too close to the project.

    Mistakes happen.  They happen more often than the deliberate acts of sabotage you are trying to protect us from.  If we protect ourselves from every danger possible we end up stuck in a bubble, unable to act from the .01% potential harm by a rouge agent.

    Frankly I was under the impression that Zendesk was more of a 'fancy forum' already.  It seems pretty basic compared to other help desk systems.  However, I prefer its simplicity and ease of use compared to the endless complexity and configurability of the other systems. 

    I presume that if an edit were made the audit trail would pick that up.  Or is the audit trail not that robust?  I am aware of change management systems that are able to document what changes are made and who makes those changes.  Is your audit trail only tracking that a change was made and not what was actually changed?  Even word processors have the ability to strike text or show that text was removed and by whom.  It would seem to me that the ability to record deletions of "f*** off" would not be impossible.  I'm not a programmer though so I could be ignorant of the degree of difficulty that a task like that may be.

    If the triggers and alerts, which I couldn’t care less about, are so important as to make edits catastrophic, give the overall admin a switch to turn editing on or off.  Then if the whole thing comes crashing down on us because of changing a typo or sentence structure it’s our fault not Zendesks.  I’ll even sign a waiver against any liability in the event my entire database goes **poof** because an edit caused a trigger to delete all of my tickets. 

  • 0

    Jamie, I understand your issue and we should look into visually truncate very large comments in the audit trail. 

    As a Solo customer you may not appreciate triggers, alerts and the other work flow functionality in Zendesk, but an uncorrupted audit trail becomes increasingly important as your team grows. 

    Email alerts are fired off the instant you update a ticket including the comment you have submitted. And then it makes no sense to go back and delete or change whatever you have written, because the customer will already have received it.

    An audit trail documents all changes to a ticket. Allowing for changes whilst preserving an uncorrupted audit trail would only grow the size of the audit trail, and would ultimately only highlight what you want to hide.

  • 0

    Unfortunately this is probably a show-stopper for us.  We need to be able to edit both the end user and admin posts to tickets.  For our business an audit trail is completely unecessary.

    Here is another security problem to highlight the need for this: an end user types their full credit card number and expiration date into a ticket (yes, people really do that!)  Leaving that number stored on your servers is a violation of our merchant account agreement, and may even have potential legal consequences.

  • 0

    In that case, Scott, you can have an admin delete the ticket.

  • 0

    Yes, we could.  But to copy the text, delete the ticket, edit the text, and then paste it into a new ticket is a lot of unecessary work.  Plus creating a new ticket would confuse our customer.  I'm starting to wonder whether we should use a system where we don't have control over our own data anyway, so I'm going to look at some self-hosted help desks too.   Thank you for your response.

  • 0

    Mikkel, I don't agree with your arguments.

    There would be design decisions to be made regarding triggers and email notifications, but that's all they are - design decisions.  There are several ways to deal with these, you just need to pick the best.  Obviously the simplest (though not best) option would be that triggers and notifications don't happen for edits.

    Nobody is asking to "mess with the audit trail", we just want to be able to edit posts -  the 2 are not mutually exclusive.  That's how wikis work - they show you the 'latest' version, but the audit trail is there if you choose to view it.

    I can understand that this might require some changes to the design and underlying structure of Zendesk, but if this is the reason you don't want to do it then please be honest with us and say that.

    Mistakes happen.  A lot more often than malicious actions do.  Part of software design is allowing for that fact.

     

  • 0

    Andy, I agree that you have a point and allowing for changes to past comments whilst preserving the changes in the audit trail can make sense, although it introduces some possible dilemmas with regard to workflow. But let me also point out, that it wouldn't solve Jamie's issue where he wants to permanently delete very long emails/messages from the trail because they clutter the interface, and it wouldn't solve Scott's issue where he permanently wants to delete credit card information in a ticket.

  • 0

    Good point, although I suppose you could design around that by making the edit audit trail visible only to admins.  In most cases where the audit trial is used to prove something, an admin would be involved anyway.  Still doesn't solve Scott's problem though - as you say there's no way around that other than deleting the ticket.

    I really like the idea of the grace period since most of the time you do spot mistakes within a couple of minutes.

  • 0

    Ok that whole integrity trail is good to know, BUT how about just making an option out of that ? There must be some way for special sysadmins to edit a ticket, is that so hard? And if you do not want that you just give that right to the super admin.

    We were just trying something with a new agent, I was explaining him that he might post private comments - he tried that but accidentially missed that checkbox. Now my end user has a test comment I can not delete EVER, the only thing would be to recreate the ticket (wtf?) or to appologise to the customer for the inconvience.

    Come on, give us a possibility for that!

  • 0

    I would suggest you apologize to the customer in any case as he has already received an email with your unintentional update. Which he would in any case regardless of you tinkering with the audit trail.

  • 0

    I'm all for keeping the audit trail sacred.  I agree that's one of the charcateristics that makes a ticket a ticket.  But, I wish I could go back and embellish / add to / express opinions on or changes I *would* have made to the history of a ticket.  Kind of like creating a branch (or a parallel timeline StarTrek terms ;-) ).  Or at least (I've requested this before) add additional new tags to closed tickets for historical reporting reasons.  But, I see Mikkel's conundrum on that; do you keep audit trail of the audit trail of the audit trail of the branch of the branch of the branch???

    But, as for cleaning up a customer facing mess because an agent f'up... that's where I'd do the "close (and maybe even delete) that ticket and start over."  The customer would probably appreciate a brand new ticket number in some circumstances.

    David.

     

Post is closed for comments.