Zendesk ticket deletion schedules: what to keep before you purge

What does a Zendesk deletion schedule do?#

A Zendesk deletion schedule is an admin-configured rule that deletes tickets automatically once they meet set conditions, typically based on status and age. It is a sound privacy and storage control, and it is also the fastest way to lose years of support history without a decision anyone remembers making.

Zendesk documents which plans include deletion schedules, which conditions are available and whether deleted tickets can be recovered, and those details change over time. Read the current admin documentation before you build a schedule, and plan as if a scheduled deletion cannot be undone.

Ticket deletion also interacts with other objects. Users, organizations, attachments and side conversations may follow their own rules, so confirm what a ticket deletion removes and what it leaves behind.

Why decide what to keep before the first run?#

Keep decisions belong before the first run because a schedule enforces the retention policy you wrote, not the one you meant. A rule that deletes closed tickets after a set period will also delete the escalation that explains a recurring defect, the onboarding thread that became a help article, and tickets your legal team asked to preserve.

Support history has uses beyond the help desk. Product teams mine it for defect patterns, QA teams use it for coaching, and AI developers building support agents look for multi-turn conversations with clear resolutions. Those uses justify keeping a defined, de-identified review set, not keeping everything.

The order of operations matters as well. If a migration, an acquisition or a storage limit is driving the purge, the export and the review sets must be finished before that deadline, so set the schedule's start date from the export plan rather than the other way around.

The pre-purge checklist#

A pre-purge checklist turns a deletion schedule from a cleanup task into a controlled records decision. Work through it with the support lead, legal and IT before the schedule is switched on.

Store the export in a form someone can read later. A JSON or CSV export with a short data dictionary describing fields, tags and custom forms is far more useful next year than a raw dump that nobody on the current team can interpret.

• 1Confirm legal holds and pending disputes, add a hold tag to affected tickets, and write the schedule's conditions to skip that tag.
• 2Map your retention policy and customer contract deletion duties to ticket conditions.
• 3Export the full ticket history to storage you control, using the export options your plan supports.
• 4Export attachments, custom field definitions, tags, macros and group structure, which give tickets their meaning.
• 5Download attachment files separately if your export lists them as links, because those links may stop working once the tickets are deleted.
• 6Capture links to Jira issues, CRM records and help center articles before ticket IDs disappear.
• 7Record ticket counts by year, brand and form so you know what existed before deletion.
• 8Define the review sets to retain, and de-identify them before storing.
• 9Test the schedule on a narrow condition, check the results, then widen it.
• 10Document the decision, the export location and the approver.

Which ticket sets are worth retaining for review?#

The ticket sets worth retaining are the ones that record a problem, the reasoning and the outcome. Short transactional tickets rarely meet that bar, while escalations and long technical threads often do.

Some sets must go regardless of their value. Tickets covered by a contract deletion duty, or tickets holding payment card or health details, follow your policy and your contracts, not a review plan.

How to balance retention value and privacy#

Retention value and privacy pull in opposite directions, and the way to reconcile them is to keep the knowledge while removing the people. GDPR's storage limitation principle, and similar rules in other privacy laws that may apply, call for keeping personal data only as long as its purpose requires, and many customer contracts promise deletion, so a review set should be stripped of names, emails, phone numbers, addresses and account identifiers before it is retained.

Detection software narrows the search; it does not end it. The maintainers of Presidio, an open-source PII detection tool, state that its automated detection cannot guarantee it finds all sensitive information and that additional protections should be used. Pair any automated pass with sampling and human review, especially for attachments and pasted logs.

Check your privacy notice as well. If it tells end users that support conversations are deleted after a period, any review set needs a basis consistent with that promise, which counsel should confirm.

Illustrative: a construction software company plans its first purge#

Illustrative: a fictional construction project management software company has run Zendesk for many years and wants to reduce storage and privacy exposure. The COO proposes a schedule that deletes closed tickets older than a set age.

Before switching it on, the team exports everything to encrypted storage, tags tickets tied to two open disputes, and defines three review sets: escalations linked to Jira bugs, implementation tickets from enterprise rollouts and conversations with QA scores. Those sets are de-identified, sampled by a support lead and archived with their issue links. Everything else, including password resets and tickets from a customer whose contract requires deletion, is left to the schedule.

The schedule runs on a narrow condition first, the results match the plan, and the rule is widened. The company ends up with a smaller, safer archive that still explains how its product was supported.

How SourceX treats a support archive before a purge#

SourceX can assess a support archive from metadata alone, such as ticket counts by year, fields in use and links to engineering systems, before any purge decision. Nothing is exported to SourceX during that fit check.

If a review set proceeds, it moves through Preparation and Approval in the SourceX five-step transaction, with personal and confidential details removed and the supplier approving the final package. The SourceX Evidence Packet records the privacy steps, and the archive stays in your own storage.