Zendesk redaction: what it removes and what it misses

What is Zendesk redaction designed to do?#

Zendesk redaction is designed to remove a specific piece of sensitive content from a ticket after it has been captured, such as a password, a card number or a document a customer should not have sent. The removal is permanent in the live ticket, which is exactly what an agent handling a privacy incident wants.

Licensing asks a different question. Instead of removing one known item from one ticket, you need to find every personal detail across years of tickets, users and attachments, including details nobody has noticed yet. Tools built for the first job leave gaps when stretched to the second.

The redaction features available to you depend on your plan, on add-ons such as Zendesk's Advanced Data Privacy and Protection add-on, and on any marketplace apps installed. Check Zendesk's current documentation for your account before relying on any capability described here in general terms.

Native, add-on and API options compared#

Redaction options around Zendesk fall into a handful of types. The table describes each type in general terms and lists what to verify, because scope differs by plan and changes over time.

Where personal details sit outside ticket comments#

Personal details in a Zendesk account sit in many places beyond comment text, and redacting a comment changes none of them. Build the export and redaction scope around this list, then confirm each item against your own instance.

• 1Ticket subject lines, which customers often write as their name plus a problem.
• 2Requester, CC and follower records, with names, emails, phone numbers and user fields.
• 3Organization records and fields, such as account owner or site contact.
• 4Custom ticket fields, especially free-text fields added for an old workflow.
• 5Tags, where teams have tagged tickets with customer or employee names.
• 6Ticket audits and events, which can keep earlier field values after a field is edited.
• 7Side conversations, chat and messaging transcripts, and voice recordings or call transcripts.
• 8Satisfaction survey comments, macros and agent signatures.
• 9Quoted email replies, signatures and inline images inside comments.
• 10Attachments of every kind, from screenshots to spreadsheets.

Why licensing calls for redacting an export, not live tickets#

Licensing calls for redacting an exported copy because in-place redaction cannot be undone and removes context the business still uses. Support teams rely on full history for repeat customers, warranty questions and disputes, and some tickets may be under retention duties or legal holds.

A bulk approach for years of ticket history#

A bulk approach treats Zendesk as a source system and does the redaction elsewhere. The steps assume an IT lead with API access and a controlled workspace for the copy.

Check what your plan and settings allow before promising a scope. Zendesk's account data export tools are not available on Team plans and must be switched on by Zendesk Customer Support at the account owner's request, although every plan can export through the REST API. Zendesk also archives tickets automatically 120 days after they are closed. Archived tickets stay reachable through search, user profiles and API endpoints but drop out of views, so an export assembled from views can silently skip most of your history.

Look for ticket deletion schedules in Admin Center before the first export. A schedule keeps deleting archived tickets that match its criteria while your project runs, and deleted tickets cannot be restored.

• 1Export tickets, comments, users, organizations, custom fields and audits through the API, and download attachments as files instead of keeping links.
• 2Test one small date range from each year of history, including archived tickets, before committing to a scope.
• 3Freeze the export with a date and a checksum so every later run works on the same copy.
• 4Decide exclusions first: voice recordings, HR-related views and tickets from customers whose contracts restrict use.
• 5Run automated detection on every text field, using your own user and organization lists as dictionaries of known names.
• 6Send long threads, escalations, low-confidence detections and kept attachments to a human review queue.
• 7Draw a random sample of the output for QA, fix any rule behind a miss and re-run the affected slice.
• 8Package the result with a field map that explains each column and placeholder.

Illustrative: a scheduling software company prepares its Zendesk history#

Illustrative: a fictional scheduling platform for commercial cleaning companies has used Zendesk since its early years. Its tickets connect customer questions to bugs in Jira and to release notes, the kind of linked history that shows how product problems were actually solved.

The support manager first tries a marketplace redaction app on old tickets, then stops on realizing that each edit is permanent and the app finds only strings someone types in. The CTO switches to an export: tickets, users, organizations, custom fields, audits and attachments go into a locked workspace.

Detection finds the expected emails and phone numbers. Review finds more: a free-text custom field called site contact holds cleaners' names, ticket subjects carry customer names, and the audit trail keeps old values of that custom field. The team redacts all three, excludes voice recordings and spreadsheets, and leaves the live Zendesk account exactly as it was.

How SourceX approaches Zendesk history#

SourceX treats Zendesk as one source system during Supply, the first stage of the SourceX five-step transaction. At that point SourceX looks only at descriptive details, such as how many years of tickets exist, which channels feed them, which custom fields are in use and whether tickets link to engineering issues; no ticket content changes hands.

Rights questions, such as customer contract limits on support data, are settled in the Rights step. In Preparation, redaction runs on the exported copy, and the field map, exclusions, queue rules and QA results go into the privacy record of the SourceX Evidence Packet.