Zendesk is a SAAS product, meaning you buy a license of the product and they provide you with hosting, storage, software, security and all other elements you expect of a good software application.

When looking at SAAS offerings we can broadly put them in three buckets:

• Seat based licensing, where you pay per active user of the tool. Zendesk falls under this bucket with its Agent based licensing. You per pay active agent in your environment
• Usage based licensing, where you pay on how much you use the product. Mailchimp is such a tool, where you pay for the amount of recipients in your email list. Sunshine Conversation is another, where you pay per active monthly user.
• Storage based licensing, where you pay for the amount of storage used. Think Amazon S3, Google Drive or other solutions.

Most SAAS tools offer a combination of these. For example, in Google Workspace, each user license comes with a set amount of storage, but you can buy additional storage if you need more.

Zendesk has always been Seat Based and didn't really have limits imposed. A ten agent environment could serve 100, 1000 or a million end-users and your bill would be the same regardless.

But this has now changed. Announced at the end of November, Zendesk will now enforce a more strict storage usage on its platform, and will bill customers with an overage upon their next renewal.

Your available storage

There's two types of storage measured:

• File Storage is the most straightforward. It's the attachments linked to your tickets, e.g. PDF files, images, signatures,....
  If you receive an email with three 5MB attachments, those would count as 15MB of File Storage used.
• Data Storage is all other data in your Zendesk: the ticket object, comments, metadata (ticket fields, attachment metadata, tags,..), users, custom objects (2kb per object). On average, a ticket with three comments counts as about 5kb of data storage if I compare the usage across multiple instances.

Zendesk calculates your available storage as follows:

[BASE STORAGE for your plan] + ([AMOUNT of agent] * [ADDITIONAL storage])

So if you have Suite Professional with 10 agents, you would have 11GB of Data Storage, and 60GB of File Storage available.

Overage

If you go over your allotted usage, Zendesk will show a notice in the Admin Center. You can then either reduce your usage by removing data or by buy additional capacity.

This is done by buying Storage Units (500 MB Data + 25 GB File Storage) and it's bought on a per-unit, per-month basis. But they don't come cheap!

Viewing Storage Limits

Zendesk has added a new Dashboard to the Admin Center to view your Storage usage. It gives you a high level overview of your current usage, and a timeline on how the data usage evolved over time.

The screenshot below shows the basic overview of storage usage in an instance that went over its File Storage:

And if you drill down into the details, you can see a curve on how the data grew over time.

Sadly, the dashboard doesn't give you any more details. You can't see which tickets cause the usage, or where the big attachments are.

How to find your overusage

Since we can't pinpoint the exact perpetrator, we can only fix this issue in bulk and work with averages. This is not an exact science, but since the amount of tickets is so big, we can assume the average per ticket is correct.

Take the example above. We know we have 50.000 tickets, and our File Usage is 60GB. This means that, on average, we have 1.2MB of File Storage per ticket.

If we want to reduce our File usage to get under the storage limit, we need to delete at least 10GB, so let's delete 15GB to be safe. That would equal deleting 12.500 tickets in our instance. This also frees up 2.5GB of Data usage at the same time.

You can calculate your own via this calculator:

Deleting Data

There are a couple of approaches to delete data. You can either do a deletion of tickets or delete only attachments in tickets.

If we delete tickets, that will also include any attachments linked to these tickets so we win storage in both tiers.
The downside is that you will lose reporting data on those tickets, so it might be better to delete a specific set of tickets (e.g. all except those Finance), or only delete attachments.

Bulk Delete Tickets

Via the Admin Center

To delete those 12.500 tickets, we can look up ticket #12500 in our Zendesk environment and note down its creation data. If we delete all tickets older than that date, we'll free up the necessary storage! For our example, let's assume ticket #12500 was created on December 13th 2021, and is thus approx 2 years, or 730 days old.

Deleting the required tickets can be done via the new Timed Ticket Deletion (EAP). Go to the Admin Panel > Objects and Rules > Settings and enable Timed Ticket Deletion, and set the value to the required amount of days.

This will start the automatic deletion of all tickets that are older in your instance, and will run continuously.

Via the API

Or, if you prefer the API route, we can use the Bulk Delete Tickets endpoint, and delete our tickets per hundred via the following command:

curl https://{subdomain}.zendesk.com/api/v2/tickets/destroy_many.json?ids=12500,12449,12448 -v -u {email_address}:{password} -X DELETE

A more granular approach

The above example works fine if you want to just get rid of the data, but it doesn't work if you need to retain some tickets for regulatory reasons, or if you want your reporting data to remain available.

One solution to get a more specific set of tickets is to do a search that returns all tickets that are, e.g., not in a specific group and delete those tickets.

Via the Admin Center

Via the Zendesk API

In the API call below, we search for all tickets that are not assigned to Finance group with ID 1234567890 and are older than 13th December 2021, since that's the date ticket #12500 in our example was created:

curl 'https://{subdomain}.zendesk.com/api/v2/search.json?query=type%3Aticket%20-group%3A1234567890%20created%3C2021-12-13' -v -u {email_address}:{password} -X

This returns a list of tickets from which you can then extract the IDs. We can then use the Bulk Delete endpoint to remove these tickets.

Via a Marketplace App

GDPR Search and Destroy

However, instead of writing the code yourself, we can also use an app like GDPR Search and Destroy by Zendesk Partner Sparkly to do this same search but without the additional coding work.

Their app allows you to Bulk Delete tickets based on search queries, and run these deletions once, or as a continuous script. It's the perfect app to fix these Data usage charges, or to keep compliant with GDPR and similar regulations.

After installing the app, you can add a Task. Choose Ticket Search as the type and search for tickets with the query -group:360001292600 created<2021-12-13 . This returns a list of matching tickets excluding the group Finance, and created before Dec 13th. Once you validate your results, you can Process these tickets to clear your storage.

Zendesk Attachment Storage Offload

If you don't want to delete the data, but rather offload the data to somewhere else so you can still reference it, you can look at solutions like Attachment Storage Offload which takes attachments and moves them to a cloud storage managed by them or yourself.

Zendesk Attachment Storage Offload

Attachment Storage Offload for Zendesk is a simple app to keep Zendesk attachments accessible while reducing storage costs.

EH7P

What about attachments?

Bulk deleting tickets will fix your storage issue, but leaves a big gap in your historical reporting. And more often than not, the issue is not the Data Storage (tickets), but the File Storage (attachments).

So a smarter way to approach this issue would be to only delete attachments of those 12.500 tickets. That way both storage tiers are in the green again, while retaining historical data.

The Zendesk API does not have an easy get all attachments endpoint, and neither is there a delete attachments option. We do however have a Redaction endpoint which allows us to remove the File Storage element of an attachment, and replace it with a 5kb reference file for the original attachment. When you redact attachments, what's left is your ticket with a reference of the attachments, and all other data intact.

Via API

Let's assume we did the work and got a list of all IDs of the tickets for which we want to remove attachments. This can be all tickets up to ticket 12500, or a more granular list that excludes some tickets in specific groups.

For each of these tickets we can call:

curl https://{subdomain}.zendesk.com/api/v2/tickets/{ticket_id}/comments.json?include_inline_images=true -H "Content-Type: application/json" -v -u {email_address}:{password}

This returns the Comments of that ticket, and an array of attachments:

{
  "comments":[
    {
      "id":16065263235986,
      "type":"Comment",
      "attachments":[
        {
          "id":16065246996882,
          "file_name":"Screenshot 2023-07-04 at 21.36.50.png",
          ...
        },
        {
          "id":16065239646098,
          "file_name":"Screenshot_2023-07-04_at_21.36.50_thumb.png",
          ...
        }
      ],
      ...
    },
    ...
  ],
  "next_page":null
  ,"previous_page":null,
  "count":2
}

For each of the attachments we can then run the following command to redact them:

curl --request PUT 'https://{subdomain}.zendesk.com/api/v2/tickets/{ticket_id}/comments/{comment_id}/attachments/{attachment_id}/redact'  -v -u {email_address}:{password}

But as you can probably guess, this gets big fast. If we assume a ticket has three comments, and each comment has 2 attachments, then we need to make a lot of API calls.

12500 tickets x 3 comments x 2 attachments = 75000 API calls!

Via Marketplace Apps

Luckily this is another scenario where we can resort to Marketplace apps like GDPR Search and Destroy to run this redaction without worrying about coding this loop for us!

The app does require you to upload a list of IDs, so we still need to export all comments for the 12.500 tickets and create a matching CSV file first.

We could do this via API, or use the Exporter app (Enterprise license or trial required). This application has a Comments export feature we can use to generate a list of comments and their attachments. When exporting, select CSV (Semi-Colon) as the export type, and make sure you select the ID, Ticket ID and Attachments URLs fields.

Once we get our export of attachments, we can upload that file in the GDPR app and run the deletion. Mind, this deletion runs client-side in your browser, so depending on the amount of data, can take a while!

Conclusion

So there we have it, a couple of approaches to handle ticket deletion in Zendesk via native features or by making use of marketplace apps.

With regards to the Data Policies I can understand a company changing its policy on how they handle data usage. Data is expensive, and most of the archived tickets in Zendesk instances are never looked at, so that's basically storage used for data that's never used.

But regardless of usage, starting to charge customers for data without offering proper tools to handle these changes is not that great. The bulk deletion options in Zendesk are either too broad or locked behind a paid add-on.

I really hope we'll see a more nuanced data-management feature in the future where we can delete tickets and attachments easily to keep us within our data limits. But until that day comes (if ever) I'm glad we've got third party options or API solutions to handle this issue when it arises!