Deleting tickets and who is allowed to

Deleting a ticket removes it from your figures as well as your queue. Who may do it, and why the thing you want is usually something else.

Deleting a ticket removes it from your figures as well as your queue. Admins may always do it; agents only if an admin has switched it on for them, which is off by default and worth leaving off for most teams.

Delete a ticket

1. Open the ticket.
2. Open the ticket options menu, top right, and choose Delete.
3. Confirm.

It then sits in the Deleted tickets view, reachable from the Views icon in the sidebar, for 30 days. Within that window you can restore it or delete it permanently; after it, it is permanently deleted automatically. Admins see that view by default and agents need permission for it.

Why deleting is usually the wrong tool

A deleted ticket is excluded from most Explore reports by default. Delete a week of spam and your volume figures for that week are wrong, which nobody notices until somebody asks why last March looks odd. You can count the deletions themselves, through the Deletions metric on the Updates history dataset, but that tells you how many went rather than restoring them to the figures they left.

What people want is almost always one of these:

• Spam: mark it as spam rather than deleting. It leaves your queue and stays counted correctly, and it suspends the requester as well, so use it on senders you mean to shut out rather than on anything that merely looked odd.
• A test ticket: solve it. One test ticket does not distort anything.
• Sensitive information in a ticket: redact the content. The conversation stays, the data goes.

A privacy request needs the opposite order

Deleting the user does not delete their tickets. It replaces their name in system fields with the placeholder Permanently Deleted User, and the tickets and their conversations remain exactly where they were.

Zendesk documents the order deliberately, and it is the reverse of what people assume:

1. Delete the personal data in the ticket conversations.
2. Delete it in Guide, Chat and Talk if you use them.
3. Only then permanently delete the user.

The reason is practical: you need the user's profile to find their personal data in the first place. Delete the user first and the tickets are still there, still containing what was supposed to be erased, and now harder to locate.

Two things make step one harder than it sounds. A closed ticket cannot be redacted, so the only way to get personal data out of a closed conversation is to permanently delete the whole ticket. And an end user who is the requester on a ticket that is not yet closed cannot be deleted at all, so those tickets have to be dealt with first: reassign the requester, or close them.

Deleting the user is itself two stages. The delete is soft for thirty days; Zendesk removes the user permanently after that on its own.

What is written down afterwards

A permanent deletion you carry out yourself appears in the audit log as Permanently deleted. The automatic removal after thirty days does not, so a ticket that quietly expired leaves no trace of who let it. Another reason to make the decision inside the window rather than by waiting.

Deleting to hide a mistake does not work

The customer still has the email. Correcting it openly is both easier and better received.

See also

• Redacting content from a ticket
• Suspending and deleting users
• Why tickets get suspended