FAQ — How do I delete a tag that’s in use?

Short answer: you can, but you usually shouldn’t. Renaming or re-parenting is almost always the better move.

What deletion actually does

When you delete a tag in Tag Management, Atender:

• Removes the tag from every conversation and incident that had it
• Does not touch automation rules (the rule and its condition or action still name this tag, but the name no longer resolves to a tag, so it silently stops matching or applying — your automation is now subtly broken)
• Does not remove references from saved filters or analytics views either
• Cannot be undone

Tag Management shows you what the delete cascades before you confirm, but not a usage count. The single-tag Delete Tag confirm names the tag and, when it has children, says how many descendants go with it; it does not tell you how many conversations have it, how many automation rules reference it, or how many reports use it. Incident links are not listed either — but deleting the tag can still remove it from incidents that carry it.

For bulk deletion, Tag Management first fetches the true cascade impact before you can confirm. The confirm action stays disabled until that preview loads. The preview tells you, in plain terms, how many selected tags, child tags, and conversation tag links will be removed. Incident tag links may also be affected, even if the preview focuses on conversation links.

When you should rename instead

If the tag’s meaning is right but its label is wrong — say it’s called Returns but you want Product Returns — just rename it. See Organize tags into hierarchies → Rename a tag.

The rename:

• Updates the label in one transaction, including the hierarchy paths of its descendants
• Does break automation rules that reference the tag by name — add_tag, remove_tag and tag conditions store the tag’s name, not its id, so a rename orphans them
• Doesn’t strip the tag from any conversation
• Is reversible (just rename again)

When you should re-parent instead

If the tag is in the wrong place in the hierarchy — say Refund Request is currently a root but should be a sub-tag of Billing — re-parent rather than delete. See Organize tags into hierarchies → Re-parent an existing tag.

No conversation strip-out, and the tag keeps its name so rules that reference it keep working — but moving a root tag under a parent clears its tag type.

When deletion really is the answer

A tag genuinely earns deletion when:

• It was created by mistake (typo, test) and has very few or zero conversations attached
• It’s a duplicate of another tag — and you’ve already migrated conversations to the canonical one (typically by bulk-tagging the old set with the new tag, then bulk-untagging the old)
• It’s been deprecated for a long time and no longer appears in your team’s mental model

In all three cases, the usage count is small, no automations reference it, and the deletion has minimal blast radius.

How to migrate a tag rather than delete it

1. Create or pick the destination tag.
2. Bulk-tag all conversations carrying the old tag with the new one.
3. Bulk-remove the old tag from the same set.
4. Update any automation rules that referenced the old tag to reference the new one.
5. Now delete the old tag — its usage count should be zero.

This way you preserve historical context (every conversation that had the old tag now has the new one) without breaking automations mid-flight.

See also

• Organize tags into hierarchies
• Bulk-tag conversations from the Monitor