Conversation tags

A conversation tag describes the subject of one specific exchange, such as negotiation, refund, duplicate invoice, or technical support. It stays with the conversation when ownership moves between agents or attendants, but it is not automatically applied to that person’s future conversations.

A contact tag has a different scope: it describes the person or your relationship with them, such as customer, hot lead, or overdue, and applies across all conversations for that contact.

Rule of thumb: if the label will remain true in any future conversation, use a contact tag. If it explains only this exchange, use a conversation tag.

Both types use the same organization tag catalog. Name, color, and ID come from contact_tags; what changes is whether the association points to the contact or to the conversation.

What Conversations shows today

In the current Conversations experience, conversation tags are available in the filter and in bulk actions. The Context → Conversation panel does not yet show or edit the tags on the selected exchange, and the chips on conversation cards are contact tags.

This means the filter may find a tagged conversation even though the label is not visible when you open that exchange. Do not treat that visual absence as proof that the association is missing.

Filter the queue

1. Open Conversations.
2. Select Filters.
3. Under Conversation tag, choose one or more tags from the catalog.

When you choose several conversation tags, the list includes conversations that have any one of them. That group is combined with the other filters — channel, inbox, state, or contact tag — so the conversation must also satisfy those other conditions.

The filter is stored in the ctags URL parameter. Current saved views do not store that parameter: after applying a view, select the conversation tags again. If a known filter unexpectedly returns no conversations, reload the screen and confirm the result without it; a failed association query is also presented as an empty list.

Apply or remove tags in bulk

1. In the Conversations list, select up to 50 visible conversations.
2. Open Actions → Organization.
3. Choose Tag conversations or Remove tag from conversations.
4. Select an existing tag and confirm.

These actions affect the conversation even when it has no external contact. In the same menu, Add tag and Remove tag affect the contact and require the conversation to be linked to one.

Each conversation is validated separately. A batch can finish partially: successful items stay changed, and failed items remain selected for correction or retry. The picker uses only the existing catalog; it does not create a new tag.

Let the agent classify the exchange

In the agent editor, open Tools → Add Tool and enable the native Conversation tags tool. It requires no additional configuration and gives the agent three actions:

• list the tags on the current conversation;
• add a tag by name;
• remove a tag by name.

When adding, the tool reuses a tag with the same name, ignoring letter case. If none exists, it creates the label in the organization catalog and applies it to the conversation. Adding it again does not duplicate the association, and removing a missing tag is not an error. The tool works without an external contact, but it needs organization and conversation context.

State in the prompt when each name should be used and when the agent should use Contact tags instead. For now, avoid % and _ in names sent to this tool: its lookup interprets them as wildcards and may find a different label.

Automations, Webhooks, and API

In Automations, the Tag conversation action applies or removes existing tags when the run has a conversation. Test mode simulates the step without writing. Automation filters also accept conversation tags with the “is any of” and “is none of” conditions. There is currently no dedicated trigger for adding or removing a conversation tag.

Event Webhooks can subscribe to conversation.tag_added and conversation.tag_removed. The public Tags API manages the catalog and contact associations, but it does not expose a public endpoint for associating tags with conversations.

Permissions and screen refresh

The Conversations route requires conversations.view. The granular model also separates conversations.reply and conversations.manage, but conversation tag policies and bulk actions still authorize the legacy Attendant role or higher. Controls can appear for a custom role that cannot complete the action, and revoking a capability may not block a legacy role. Do not use button visibility as proof of access; validate the role from the operation result.

A change made by the agent, an Automation, or another session does not invalidate the current list in real time. Reload Conversations before making operational decisions based on the filter or on the apparent absence of a tag.

Best practices

• Define a short, stable vocabulary such as billing, cancellation, and technical question.
• Use conversation tags for subject, handoff reason, and request type; use contact tags for segment, stage, or a lasting property.
• Give the agent preferred names so it does not create synonyms on demand.
• In bulk actions, review the items that remain selected after a partial result.
• Before measuring volume by subject, reload the list and verify that the Conversation tag filter is applied again.