> ## Documentation Index
> Fetch the complete documentation index at: https://docs.orbit.devotel.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Inbox tags — the vocabulary routing, filters, and reporting run on

> Define the inbox tag vocabulary — names, colors, and descriptions — from Inbox → Settings → Tags. Learn how active and archived tags behave, how a rename propagates across history, how routing rules match on tags, and why a rule that never fires usually points here.

# Inbox tags — the vocabulary routing, filters, and reporting run on

Tags are the shared vocabulary everything downstream depends on. A routing rule matches on a tag, a saved view filters on a tag, a conversation-intelligence operator extracts a tag, and dispositions label close-out with a tag-shaped vocabulary. The **Tags** console under **Inbox → Settings** is where you curate that vocabulary — the names agents apply, the colors the chip rail renders, and the descriptions that tell agents when to apply each one.

Until a tag exists in this console, everything downstream that keys on it fires on nothing. Create the vocabulary here first; then routing, filters, and automation have something to match.

Every control on this page is tenant-owned — you own your workspace's tags, and no tag is applied to a conversation until you or an agent applies it.

## The tag vocabulary

Each tag definition has three fields plus a lifecycle state:

* **Name** — the label agents see and apply, 1 to 40 characters. Names deduplicate case-insensitively, so `VIP` and `vip` are one tag. The name is the value that actually lands on a conversation when the tag is applied.
* **Color** — the swatch the chip renders with. Pick from the preset palette or choose a custom hex color; the default is a neutral slate. Color is display metadata only — it never affects matching.
* **Description** — optional, up to 280 characters. The description shows as the chip's tooltip, so write it as guidance to the agent deciding whether to apply the tag ("Apply when the customer explicitly asks about pricing"), not as a note to yourself.
* **Active vs archived** — a tag is active until you archive it. Active tags appear in the tag picker; archived tags do not. History is never lost either way.

A workspace can hold up to **500 active tag definitions**. That is far beyond the human-usable range — ticket taxonomies stay readable to agents well under 100 — the headroom exists for automation-seeded vocabularies (one tag per skill, per segment, per disposition fallback).

The console is role-gated to **owner and admin** for writes. Every operator can read the vocabulary.

## Walkthrough — create a tag and put it to work

Open **Inbox → Settings → Tags** (owner or admin). The page lists your active tags; toggle **Show archived tags** to include archived ones.

1. **Create a tag.** Click **Create tag**, set the name (for example `refund-requested`), pick a color, and write the description as agent guidance. Save.
2. **Apply it.** Agents apply the tag from the conversation thread's chip rail — the picker only ever offers active tags. The tag name lands on the conversation and is immediately filterable and matchable.
3. **Match on it in routing.** Create or edit a rule under **Inbox → Settings → Routing** and add a **tag match** condition naming `refund-requested`. Any conversation carrying that tag now satisfies the condition. Dry-run the rule against recent conversations before enabling it.
4. **Filter on it.** In the inbox list, filter views and saved views on the tag. Operators and reports read the same applied-tag data the filter shows.
5. **Close with it.** Dispositions and close-out vocabularies compose with tags — see [Conversation operators](/inbox/conversation-operators) for how outcome labels and tags interact.

## Where tags land

An applied tag is a string on the conversation. Three surfaces read it:

* **Dashboard filters** — the inbox list filters on tags, and saved views persist a tag filter across sessions.
* **Operators and reporting** — conversation-intelligence operators can read applied tags as signals, and ticket/conversation reports group on them.
* **Automation** — routing rules, ticket automation, and macro conditions all evaluate the same applied-tag set.

Because the definition table curates names and the applied set carries strings, a tag with zero current applications stays visible in the console and in routing-rule previews — you can pre-seed the vocabulary before any conversation carries it.

## Archiving semantics — locked from use, history kept

Archiving is a soft-delete, not a deletion:

* **Archived tags leave the picker.** Agents can no longer apply the tag to new conversations.
* **History is untouched.** Conversations that already carry the tag keep it; filters and reports on the tag keep working.
* **Reversible.** Unarchive restores the tag to the picker instantly. The **Show archived tags** toggle on the settings page is a per-operator view preference — archived definitions always exist, you just choose whether to see them in the list.
* **Nothing else can claim the name.** A name matches a single definition whether that definition is active or archived, so retiring a tag does not open the name for a different color or description.

Archive when a season, campaign, or cleanup retires a tag. Never delete a tag by renaming a new one over it; archive the old one instead.

## Editing and renames

Editing a tag updates its color and description in place. Renaming is stronger: a rename propagates across every conversation that carries the old name, in a single update, so your historical filters stay true after the rename. This makes rename safe for fixing a typo or normalizing two near-duplicates — and makes archive the right tool when you want the vocabulary to shrink, not just change spelling.

## Composing with routing rules — the on-tag match predicate

Routing rules evaluate a condition set; the **tag match** condition reads the tags currently applied to the conversation. Combined with channel, keyword, sentiment, and time-of-day conditions, tag match is the way you express "VIP handled by senior agents" or "billing goes to the billing queue."

Two rules of thumb:

1. **Define first, match second.** A rule that matches on a tag only fires once a conversation carries that tag — and only tags that exist in the vocabulary are applied with any consistency. Create the tag here before you write the rule.
2. **Dry-run before enabling.** The routing console's dry-run evaluates the rule against recent conversations and shows which ones would match. A dry-run that matches zero conversations because the tag was never applied is the cheapest possible catch.

## API parity

Everything this page does over the dashboard has an API equivalent — list, create, update, archive, and unarchive — documented in the [Inbox endpoints reference](/api-reference/endpoints/inbox). The same endpoints also distinguish the curated vocabulary (`/inbox/tags`) from the applied-tag surface.

## Troubleshooting

| Symptom                                                | Cause                                                                                             | Fix                                                                                                                                |
| ------------------------------------------------------ | ------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------- |
| **Routing rule never fires**                           | The tag the rule matches on does not exist in the vocabulary, or no conversation ever carries it. | Create the tag under **Inbox → Settings → Tags**, confirm agents can apply it (it must be active), then re-run the rule's dry-run. |
| **Agents cannot find a tag in the picker**             | The tag is archived, or was never created.                                                        | Toggle **Show archived tags** on the settings page; unarchive it, or create it.                                                    |
| **Two tags differ only by casing (`VIP` vs `vip`)**    | Names deduplicate case-insensitively; the second create attempt was the right behavior to block.  | Keep one; archive the other. The surviving tag covers both spellings.                                                              |
| **A rename lost its history and filters went empty**   | The rename propagated, but a filter still references the old spelling.                            | Update the saved view or report filter to the new name. The conversations themselves moved correctly.                              |
| **A tag needs to disappear but reports still need it** | Hard-deleting is intentionally impossible — archive keeps history by design.                      | Archive the tag. Reports and filters on historical conversations keep working.                                                     |

***

Related: [Inbox settings map](/inbox/settings-map) · [Conversation operators](/inbox/conversation-operators) · [Inbox endpoints](/api-reference/endpoints/inbox) · [Inbox setup](/guides/inbox-setup)
