Deleting Zendesk tickets for GDPR retention, with a dry run and evidence

1. Write the criteria as a query, not as a sentence

"Closed tickets older than two years" becomes type:ticket status:closed created<2024-09-12. Decide whether "older than" means created or solved, whether closed only or solved too, and whether some brands, forms or tags are exempt (legal holds, complaints). In Data Custodian the rule editor renders the exact query it will send, and the same criteria can be saved as a search to review the candidates first.

2. Add a guard for activity

A ticket can be closed and still matter: a follow-up was created from it, a customer wrote again, an agent added a note. Append updated<date so tickets touched in the last 30 (or 90) days are never in scope. Data Custodian's rules have this guard as a field, added to the query on every run.

3. Dry run: count, sample, cap

Before deleting anything, get the exact count for the whole account (Zendesk's search stops at 1,000; use the export endpoint or the app), look at a sample of ten, and cap the first run (500, then 5,000). The dry run in the app shows four numbers: how many match, how many this run would process, how many the guard skipped, how many wait for later.

4. Soft delete first

Zendesk keeps deleted tickets for 30 days in the deleted tickets list, restorable by an admin. Delete, wait a week, listen for complaints, then delete permanently. Data Custodian shows the list inside the app with restore and permanent delete, both with typed confirmation.

5. Redact where deletion is too much

Some tickets have to stay (warranty, disputes, tax) but the personal data in them does not. Redact instead: e-mail addresses, phone numbers, card numbers, IBANs, national ids, and attachments. The app's redaction packs check card numbers with Luhn and IBANs with mod 97 so a random number is not touched, preview every string masked before replacing it, and keep the longest match when two packs overlap so nothing is left half-visible.

6. Keep evidence

For every run: who, when, the query, the guard, the cap, how many were deleted, how many failed and why, and the ids. Data Custodian records this automatically as an event, exportable as CSV or a printable report, and on Business and up also as records of a custom object inside your account so it survives the admin's browser.

Doing it with Zendesk alone

• Views can bulk-delete 100 tickets at a time from the agent interface; no dry run, no evidence beyond the audit log on Enterprise.
• The Advanced Data Privacy and Protection add-on has deletion schedules (a policy that runs on its own) and redaction inside the ticket; priced per agent. Compared here.
• The API: DELETE /api/v2/tickets/destroy_many.json?ids=… in batches of 100 as background jobs, then DELETE /api/v2/deleted_tickets/destroy_many.json for permanent deletion, PUT /api/v2/tickets/{t}/comments/{c}/redact.json with the exact string for redaction. Works, needs code, a token, a ledger so a crashed script does not repeat batches, and your own evidence file.

Doing it with Data Custodian

1. Retention → New rule: name, criteria (the builder offers status, dates, tags, brands, forms, custom fields), action (delete, delete permanently, redact attachments, anonymise), guard days, maximum per run.
2. Dry run: the four counts and a sample table; the exact query is shown at the bottom.
3. Type "RUN 500" and the app runs batches of 100 through Zendesk's job endpoints, with pause and stop, per-ticket results and a ledger so a closed tab never repeats a batch.
4. Audit: the run is an event with the rule id; export the period's events as CSV or the printable report for the file.

Retention runs are admin-only and available on the Business and Enterprise plans. Nothing runs unattended: a rule waits for an admin to dry-run and confirm it.

Related: exporting tickets with comments before deleting · the ADPP add-on compared · try the demo.

Support: support@helpcenterdoctor.app.