Recent searches


No recent searches

Matt Savage's Avatar

Matt Savage

Joined Apr 15, 2021

·

Last activity Feb 10, 2023

Following

0

Followers

0

Total activity

54

Votes

33

Subscriptions

16

ACTIVITY OVERVIEW

Latest activity by Matt Savage

Matt Savage commented,

CommentTicket customization

I Agree with Sascha above - different brands, groups, products, workflows, etc. would benefit from specific statuses.  I would like to configure this as part of customizing agent workspaces.

View comment · Posted Feb 10, 2023 · Matt Savage

0

Followers

13

Votes

0

Comments


Matt Savage commented,

Community comment Feedback - Ticketing system (Support)

(edit: 2018-05-18 13:44 - post is pending approval still- check later if you don't see it yet)

Since it's relevant to the points above, I'm cross-posting my best attempt at enacting a deletion/retention process with the current API endpoints.  I hope this provides more depth into just how under-equipped the current features are to comply with the necessary data policies imposed by GDPR.

View comment · Posted May 18, 2018 · Matt Savage

0

Followers

0

Votes

0

Comments


Matt Savage commented,

Community comment Feedback - Ticketing system (Support)

Haha, thanks for the compliments Stephen & Dan.  I posted this because I expected many other Zendesk customers were experiencing similar limitations with managing data effectively.  Maintaining balance between your own business needs and your own customers is tricky business, as well all know well.  There are lots of opportunities to automate the policies to reduce potential errors in their application.

WRT closed tickets: I had also asked about this initially and failed to include it above.  I also want to know what can be done to handle those more tactically.  I have no issue with immutability at a certain state but it'd be nice to have control over exactly when that transition occurs.  Currently, there's an artificial 28-day maximum on the transition from solved --> closed that can't be overridden.  That's another aspect that would be great to specify directly in data retention/anonymization policies.

View comment · Posted Apr 23, 2018 · Matt Savage

0

Followers

1

Vote

0

Comments


Matt Savage created a post,

Post Feedback - Ticketing system (Support)

There have been a number of prior community posts around GDPR topics, including:

  1. https://support.zendesk.com/hc/en-us/community/posts/360000867987-GDPR-redaction-on-closed-tickets- 
  2. https://support.zendesk.com/hc/en-us/community/posts/360001117827-GDPR-Automatically-deleting-old-tickets-via-the-automation-feature
  3. https://support.zendesk.com/hc/en-us/community/posts/115008423827-Enable-editing-deleting-comments-and-attachments-in-tickets 
  4. https://support.zendesk.com/hc/en-us/community/posts/203439166-Add-ability-to-bulk-delete-closed-tickets 
  5. https://support.zendesk.com/hc/en-us/community/posts/245247207-General-Data-Protection-Regulation-2018-the-right-to-be-forgotten

@Joel Hellman posted a solid list that captures a variety of concerns, many of which I share and believe are worthy of a larger discussion about GDPR tools/features that Zendesk customers need to support their own compliance needs.  The current methods of handling GDPR responsibilities are technically compliant, but simply aren't nuanced enough for us to balance legal compliance with our own teams' needs for efficiency, reporting, and consistency and our own customers' ability to control their data.  Below are some features I believe would address those issues without requiring Zendesk customers to have a developer-level of competence with the API.  (Warning: long read ahead)

--------------------------

Similar to how SLA policies exist independently of other Zendesk features, I believe a robust feature for capturing all Data Management policies under a single umbrella is a potential solution.  Attempting to align the various aspects across different configurations and features would offer a fractured, confusing experience for admins attempting to create clear, manageable data polices that align with their business needs.  As with SLAs, attributes can be added from other sources (e.g. triggers, automations) to determine which policy applies to any given ticket.  However, a single feature should serve as the source of truth for data policies, system-wide.  Components of such a policy might include:

-----------------------------

Data Retention

Admins should be able to configure global retention policies that are attached to each ticket, same as SLAs.  These policies can apply to fields for consistent data handling processes across tickets.  They also allow admins to designate which fields' data can be retained (e.g. non-PII data that's used for analytics), allowing teams to maintain valuable data in their reports/dashboards.  Flexible policies can also be defined for tickets or users that meet specific GDPR challenges, such as data that must be retained for ongoing litigation.

Configuration options:

Tickets

  • Delete [ticket fields] when [conditions] are met (configure like SLAs/triggers)
  •     Multi-select list of fields to delete when [conditions] are met.  This could include 'smart' defaults like 'all' that would allow admins to efficiently exempt whichever fields they don't want deleted.

Users

  • Delete [user fields] when [conditions] are met.
  •     Multi-select list of fields to delete when [conditions] are met.  This could include 'smart' defaults like 'all' that would allow admins to efficiently exempt whichever fields they don't want deleted

 

Attachments

Attachments pose a particular problem, as they are not always subject to the same policies as other ticket data.  Sometimes a ticket can be closed, anonymized, and deleted, but the attachment must be retained for a much longer time due to other legal compliance reasons.  Thus, attachments may require separate policy controls than tickets themselves.

Configuration options:

Tickets

  • Delete [attachments] when [conditions] are met (configure like SLAs/triggers)

Ephemeral upload channels

Ephemeral upload channels would solve the problem of handling extra sensitive information.  The reason for separating this from general retention policies above is this: sometimes attachments and other ticket data don't have the same level of sensitivity.  These could be handled by the attachment policies above, but a new feature to manage upload channels (similar to email forwarding) would be helpful, as it could be a used in the criteria of those policies (e.g. attachments coming through a 'burner' channel would be treated differently than a 'standard' one that has a longer retention period).  From a liability perspective, there is some information (e.g. passports, ID cards, and other identity documents) that is best handled in a "Snapchat" manner - once it's served its purpose, it can (and should be) discarded as soon as an issue has been resolved.

 

Data Anonymization

Deleting tickets to maintain compliance will cause irreversible loss of data.  Instead, the original ticket should be retained but with any potential PII information scrubbed/anonymized as necessary.  Admins should have simple ability to select which fields should/shouldn't be anonymized for each policy.  This policy would need the ability to modify tickets in the 'closed' state to be fully effective.

Configuration options:

Tickets

  • Anonymize [ticket fields] when [conditions] are met (configure like SLAs/triggers)
  •     Multi-select list of fields to anonymize when [conditions] are met.  This could include 'smart' defaults like 'all' that would allow admins to efficiently exempt whichever fields they don't want scrubbed.
  •     Advanced > Regex matching - support automated data anonymization when custom patterns are met (same as credit card redaction works now).  A 'tester' regex wizard that allows admins to see which ticket data would be affected prior to enabling them (same as automation previews) would make this more accessible to admins who don't have development resources.  A more complex version would display a list of ticket data prior to anonymization that would require manual approval

 

Customer Control

Data Export

Users should be able to easily download & export their Zendesk data in a portable format (i.e. .zip archive of .csv or .json files) with optional encryption password.

Data Deletion/Right to be Forgotten

Users should be able to submit deletion requests into an admin tool/interface.  Manual requests of this nature are cumbersome to manage if they can't be initiated by the data subject directly.

  • Allow users to manage their own data
  •     Multi-select list of user fields users can delete
  • Allow users to manage their ticket history
  •    This relies on the ticket policy attached to each ticket in their history.  Users can choose to delete their tickets, triggering the deletion policy attached to each on if it hasn't already run.
  •          A bulk delete option should be prominently displayed in the customer's ticket history for customers to initiate ticket deletion (subject to overriding retention policies enumerated on the individual tickets in the section above).

 

Auditing

The ticket event log is fairly robust as is, but 3 general additions would greatly enhance Zendesk auditing for compliance purposes:

  1. Full details in the audit log: (e.g. https://domain.zendesk.com/settings/account/audits?filter[source_id]=1234567&[source_type]=rule). Currently, it shows that changes were made when you hover over an entry, but you can't see what the full differential in the configuration changes (this is somewhat addressed in other places by trigger revision history).
  2. Ticket viewer history:  A record of any event where a ticket was viewed - there's no current access log that I'm aware of.  In case of a privacy event or data breach, knowing who has accessed a ticket is critical information.
  3. System config differentials: Understanding the day-to-day changes in a complex system of triggers, automations, macros, 3rd party apps, and more is nearly impossible.  This is exacerbated when attempting to test new features & deploy them to production.  Zendesk would benefit greatly from a robust change log & versioning process that's commonly used in code deployment.  Enabling complex rule sets can be tricky and this functionality would allow for both better auditing and simpler reversion if errors are introduced during a big change.  Manual rollback is extremely painful and can lead to cascading issues system-wide if not executed properly.

Posted Apr 20, 2018 · Matt Savage

19

Followers

26

Votes

17

Comments


Matt Savage commented,

Community comment Feedback - Ticketing system (Support)

SMTP would allow a workaround for some really obnoxious email looping logic for automated systems.  

For example, if you have notifications sent from some other source, it'd be nice to sync via SMTP to get that content into Zendesk & allow replies to that same email (essentially, pretending that these emails originated in ZD).  This is a common email behavior: email@domain.com sends out a bulk mailing, responses return to that same place form the recipients.

Instead, to avoid looping addresses that forward into ZD, you'd likely have to do something like this: noreply@domain.com (with reply-to:forwarded_email@domain.com) sends the email to recipients@domains.com, CC's forwarded_email@domain.com to ensure that the notices are sent into ZD via email processing.  You'll also need triggers to push the status to pending/solved immediately, as you need to wait for the actual customer to reply (if they do).  It adds a great deal of complexity to the simple task.  The other alternative is configuring automated systems to send the original message via the ZD API; while this is doable, it requires more dev resources & counts against your API usage, which can be hard to balance with bulk mailing events, even when attempting to distribute the load.

View comment · Posted Oct 13, 2016 · Matt Savage

0

Followers

0

Votes

0

Comments