What are the Historic attributes in Insights? Follow

Comments

5 comments

  • Avatar
    Joel Hellman

    This article is helpful, but I would love to see an example use case.

  • Avatar
    Bernd Sawatzki

    Hallo ,

    in which dataset ( in incremental exports / api ) can we find these historic fields ???

    Regards

    Bernd Sawatzki

  • Avatar
    Amy Dee

    Hi Joel! Sorry about the delay! There are a lot of use cases where the Historic attributes could be helpful. For example, you could find all tickets that were ever in Urgent priority, which agent was assigned to a ticket before it was escalated, or which group logs the most handle time.

    Here's a quick example that uses satisfaction ratings. In this ticket, "Sally Staff Agent" got a bad rating. Then, agent "Amy Dee" took over, and the customer changed their rating to good. The ticket attributes - Ticket Assignee and Ticket Satisfaction Score - show the current rating and current assignee. However, with Ticket Assignee (Historic) and Satisfaction New Value, we can see who was assigned at earlier ratings:

     

    To Bernd - the Historic attributes are only available in Insights. They aren't stored as data points in the incremental or audits API. The API endpoints focus on the values that actually change.

    In Insights, the Historic attributes are stored in the "System Field History" dataset, which is connected to the "Ticket Text Field Change," "Ticket Numeric Change," and "Satisfaction Survey Change" datasets.

  • Avatar
    Bernd Sawatzki

    Hallo Amy,

    we want to count the tickets a certain agent worked in on a certain date, where the (historic) ticket-group to this date has a certain value.

    I tried with ticket-comments or ticket-updates, but there can be more than one comment / update in one ticket, so my report ( counting tickets ) is not correct !?!

    Do you have an idea, how wo can solve this problem / reporting ...

    Bernd Sawatzki

  • Avatar
    Amy Dee

    Hi Bernd! This type of reporting is difficult, because the best approach depends heavily on your workflow.

    There is one thing we can clear up here, though. The # Ticket Updates metric is SELECT COUNT(Ticket UpdatesTicket Text Field Change). This means the metric is counting individual updates with at least one matching text field change. 

    If you're interested in counting whole tickets instead, you need a metric that starts with this: SELECT COUNT(Ticket IdTicket Text Field Change). This means it counts tickets with at least one matching text field change. (You would use the rest of the metric to identify what type of change you're looking for.) With this type of COUNT, each ticket will count once per report slice, even if there are multiple matching updates.

    The count is simple enough to fix. The rest gets tricky, since there are a lot of moving parts. I'm going to start a ticket for you, so we can look at specific examples from your account.

    Watch for my email, and happy reporting!

Please sign in to leave a comment.

Powered by Zendesk