9 Comments

  • David Hall
    Comment actions Permalink

    Today we have added new event type "Custom Field Changed".

    The event includes a "custom_field" object with three parameters:

    • Id: the Zendesk ID of the custom field
    • Raw_title: the name of the custom field
    • Field_type: the data type of the field (date, text, numeric, multi-select, etc)

    One Custom Field Changed event will be emitted for each custom field that is changed during a transaction.  For instance, if a support agent changes three custom fields before clicking "Submit", three Custom Field Changed events will be emitted.

    1
  • David Hall
    Comment actions Permalink

    We have now added another new event type, "Problem Link Changed".

    This event indicates when an Incident ticket has been linked or un-linked to a parent Problem ticket.

    • If the previous value is null, this indicates that the ticket was not linked to a Problem ticket before.
    • If the current value is null, this indicates that the ticket is no longer linked to a Problem ticket.
    • Otherwise, the previous and current values indicate the ID of the Problem ticket this ticket is linked to.

    For more information about linking tickets, please see this article about working with Problem and Incident tickets.

    0
  • Bryant Vasquez
    Comment actions Permalink

    David Hall / Darren Chan

    I see that problem link was added in for distinct problem link changes, but would it be possible to have the problem link included for all incident ticket events? The reason I ask is this, we ingest this data into elastisearch for visualization. Right now, based on events from tickets being created, and then comments being added to those tickets, custom fields getting filled out, and the ticket getting linked to a problem, we can see trends in new tickets and in new links to a problem. However, if five incidents were linked to a problem and mostly dormant, but then they started getting a flurry of comments, we would have no way to visualize that increase of impact for the overarching problem as those incident ticket events only report the problem when that link is changed. 

    I hope that explains why the linked problem for an incident would be crucial at all stages (for non-linked incidents the filed could just be linked_problem:null). As we need to be able to see when comments for incidents linked to a problem start to spike, indicating that there may be something trending with that problem. It seems the data is already there, so if it can just be added to the main schema, that would be great!

    1
  • David Hall
    Comment actions Permalink

    Thanks for the feedback Bryant, I get what you're asking and we'll take that on board.

    0
  • Bryant Vasquez
    Comment actions Permalink

    Also, something else, when a new ticket is created, I get about eight events, changing the brand, changing the status, assigning the ticket, and a different event for every single custom field that is set. This creates a lot of noise at ticket creation time. It makes sense to have an event every time a custom field is changed after creation, but at ticket creation would it be possible to just get one event that has all of the data of the ticket that would be included in ticket.json? Post-ticket creation it makes sense to have all the events, but at creation it just creates a lot of overhead to de-dup for analytics to have so many events for changes, as they aren't technically "changes" they are all ticket creation data. 

    0
  • David Hall
    Comment actions Permalink

    Hi Bryant,

    In parallel to the existing events we are exploring the idea of adding an "entity stream", which would provide a snapshot of the ticket each time it changes.  It sounds like this might cater for what you're suggesting, so I'll create a ticket so we can discuss in more detail.

    0
  • Bryant Vasquez
    Comment actions Permalink

    That would actually be an incredible improvement. As it is, our elasticsearch kibana gets a little crowded on ticket creation with a new event for a change in every single custom field. If we could just get a single snapshot with every custom field name, field value, tags, status, problem link, etc, that would be amazing for our data ingest and visualization. 

    Any chance there is an ETA on that, and if so/not would a muffin basket help? :-D

    0
  • David Hall
    Comment actions Permalink

    Glad to hear that sounds helpful.  No ETA yet as we have a number of technical challenges to work through both internally and with AWS, as well as wanting to gather customer input.

    Sadly, muffins are unlikely to get us there faster (unless they can code).

    0
  • David Hall
    Comment actions Permalink

    We're pleased to announce that four more Ticket event types have been added to the Events Connector.

    • Email CCs Changed
    • Followers Changed
    • Attachment Linked to Comment
    • Attachment Redacted from Comment

    You can find more information about the fields contained in each in the example schemas here.

    0

Please sign in to leave a comment.

Powered by Zendesk