Sometimes it can be hard figuring out what is going on behind the scenes with a ticket. Has the priority always been high? Who escalated this ticket to the spam group? Has anyone seen an email notification lying around? I swear I sent one out a second ago...
You don't need to be in the dark about the inner workings of your tickets--and you don't need to log a ticket with the our customer service team to find out what's going on. You can see an audit trail of every change that occurred to a ticket by viewing events instead of the default plain old boring comments for a ticket.
This is where the magic happens.
Events shows all the information that Comments does, but with a whole bunch more information. You can see when each and every aspect of your ticket was set, when any ticket field was changed, and when any email notifications went out and which trigger our automation caused it to happen. Literally, every aspect of your ticket's life is available to you at any time.
'That's all good and well" you might smugly remark, "but why should I care when my ticket was changed from a question to a problem?" It's quite important, I respond with eyes gleaming. Almost any issue with your business rules can be discovered by looking at events for the ticket.
Let me give you a example. I've had multiple tickets where a customer is unable to change a ticket field. They click the drop down, change the field, update the ticket, and nothing happens. If this has happened to you, you might want to take a look at the events for the ticket. Many times a trigger has been created that prevents the ticket field from changing. In events, you can see each of these attempted field changes and the dastardly trigger changing it right back!
In the following image, you see that I attempted to change the custom ticket field 'Camera Type' several times, but each time it was switched back to Movie::Digital. Looking at comments, you don't know that. Viewing events, however, you see each event where the ticket was updated and every action a trigger took because of it.
In this example, the trigger "Worst trigger ever" switched the ticket field and tags back to their original settings and that is the why changing the ticket field and updating the ticket did nothing. Knowing that, you can go into triggers and either fix the logic or remove that trigger from the system. This works for email notifications as well.
Now, here's another common example where viewing events comes in handy: I can't tell you how many Zendesk Support users write in because their end-users say they haven't received an email and they want me to check to see if our system sent out an email to the end-user. Well, actually I can tell you the number, because we keep an archive of all of our closed tickets, and its probably not a huge number, but I like to complain!
If you look at events for a ticket you can see if an email was sent out, who it was sent to, and the trigger that caused the email to be sent, as shown in the following image. This can also be useful in identifying multiple notifications being sent out and tracking automation notifications that won't appear when you look at comments.
Having the ability to audit your own tickets and know which exact trigger or automation is causing which action is incredibly useful in detecting and resolving issues. When we as advocates get a question about email notifications not going out or ticket fields not being able to update, this tool is almost exclusively what we use. I might have given you all one of our greatest secrets as an advocate... but if it helps you resolve your own issues instead of sending in a ticket, then I think we'll manage!