Zendesk Tags

Zendesk tags are the cheapest thing to add and the hardest to clean up. Six months of casual tagging leaves a list nobody can report on.

The six ways Zendesk tags land on a ticket

People ask how to add tags in Zendesk expecting one answer. There are six, and most tags on your tickets arrived through the ones nobody thinks about.

By hand. An agent types into the tags field in the ticket properties panel. Autocomplete suggests existing tags, which is your main defence against spelling variants.
From a field. Every drop-down option and every ticked checkbox applies its own tag automatically. This is where most tags come from.
From a macro. Macros can add tags as part of the action set.
From a trigger or automation. The heaviest source, and the one that can do the most damage.
From the API. Tickets carry a tags array, and there are dedicated endpoints for adding and removing.
Inherited. Tags on a user or an organization can be applied to new tickets from them, which is genuinely useful for VIP handling and confusing when you can't work out where a tag came from.

Set tags versus add tags

This is the one that breaks accounts, so it gets its own section.

Add tags appends. Whatever is already on the ticket stays, and your tags join it. Set tags replaces the entire tag list with exactly what you specified. Remove tags takes specific ones off.

A trigger configured with Set tags wipes every tag another rule applied, including the ones your reports depend on and the ones your other triggers use as conditions. It works fine when you test it on a fresh ticket. It quietly destroys data on real ones, and by the time somebody notices, a month of reporting is wrong.

Use Add tags in triggers, automations and macros. Set tags has exactly one legitimate use, which is deliberately clearing and rewriting the list, and you'll need it about once a year.

Go and check your existing triggers now. Most accounts have at least one Set tags that somebody chose from the drop-down without reading it.

Tag hygiene

Tags have no schema, no validation and no owner. That's why they rot.

Pick a separator and stick to it. Spaces become underscores automatically, so billing_refund and billing-refund will both exist unless you decide.
Prefix by domain. product_, reason_, channel_. Sorting the tag list then groups related tags together, which makes an audit possible.
Never let a tag be the only record of something important. Anyone can delete a tag from a ticket, with no audit trail and no confirmation.
Audit twice a year. Admin Center lists tags with usage counts. Anything used under a handful of times is noise. Anything that looks like a misspelling of a real tag is a reporting hole.

Zendesk applies some tags itself. closed_by_merge lands on the ticket that was closed during a merge, which is a useful one to know and a useful one to exclude from your volume reports.

Reporting on tags

Explore exposes tags as an attribute, and the trap is arithmetic. A ticket with four tags appears in four rows. Sum a tag breakdown and you get a number larger than your ticket volume, every time.

That is correct behaviour and it looks like a bug in a screenshot. Report on tags as a percentage of tickets containing the tag, never as a share of a total that adds to a hundred.

If you want a clean, mutually exclusive breakdown, you want a drop-down ticket field, which allows one value per ticket and applies a tag anyway. Best of both.

When a tag is the wrong tool

Tags are a flag. The moment you want to store a value, they stop being appropriate.

You cannot report on a tag numerically, sort by it meaningfully, validate it, or make it required. So a tag is wrong for an order number, wrong for a date, wrong for anything the customer types, and wrong for a category you plan to build a dashboard on.

Use a custom field for values, a drop-down for categories, a user or organization field for anything true about the person rather than the ticket, and a tag for a temporary flag you need triggers to read. That last one is what tags are actually good at, and they are very good at it.

FAQ

Frequently asked questions

What's the difference between set tags and add tags?

Zendesk set tags vs add tags is the difference between replacing and appending. Set tags wipes the existing list and writes yours; add tags leaves what's there. Using set in a trigger is how teams quietly delete their own tagging.

How do I add tags in Zendesk?

Type into the tags field in the ticket properties panel, or apply them automatically from a macro, a trigger, a drop-down field value or the API. The automatic routes account for most tags on a typical ticket.

What is the difference between set tags and add tags?

Add tags appends to whatever is already there. Set tags replaces the entire list, wiping tags applied by other rules. Use Add tags unless you specifically intend to clear everything.

Can end users see ticket tags?

Not in the standard help centre view. Tags are an agent-side construct, though anything you put in a tag name can leak through integrations and exports, so avoid anything sensitive.

How many tags can a ticket have?

There is a practical limit, and it is far higher than anything sensible. If a ticket carries more than about ten tags, the problem is your tagging strategy rather than the ceiling.

Can I bulk remove a tag from old tickets?

Through the API, yes, and it is the usual route for cleaning up a deprecated tag. Test on a small batch first, because updates can fire triggers.

One tag Zendesk adds for you

Every merged duplicate gets tagged closed_by_merge. Ticket Merger creates those merges automatically, so the duplicates leave your queue without an agent touching them.

Start free trial

14-day free trial. No credit card required.