> ## Documentation Index
> Fetch the complete documentation index at: https://knowledge.goautonomous.io/llms.txt
> Use this file to discover all available pages before exploring further.
# Tag requests with deterministic rules
> Create tag groups with custom rules that classify and route incoming requests based on mail content and captured field values.
## Overview
The **Tags** page in Axon lets you classify incoming requests with deterministic, rule-based tags. Unlike intent classification, which uses AI, tags apply predictable rules that you define yourself. When a request matches a rule, Axon applies the tag. This gives you an exact, repeatable way to flag and route requests, for example marking those from a specific customer list or orders above a quantity threshold.
Tags are organized into **tag groups**. A tag group defines where the tags apply (scope), which tags belong together, and how Axon picks a winner when several tags match.
The Tags page is being rolled out gradually and may not be visible in your Axon side menu yet. Reach out to your Engagement Manager if you'd like access.
## Who can manage tags
Creating, editing, and deleting tag groups requires **Editor** access to Axon. Users with **Viewer** access can browse tag groups but the create and edit actions are hidden. See [permission levels by product](/knowledge-base/administration/access-control/permission-levels) for a full breakdown.
## Creating a tag group
Open **Axon → Tags** and click **Get started** (or **Create** if groups already exist). The creation wizard has three steps: **Configuration**, **Tags**, and **Dry run**.
Give the group a name and choose its settings:
* **Scope** — apply the group to specific **Inboxes** or **Areas**, then select which ones.
* **Intents** — optionally narrow the scope to specific intents. The group then only evaluates requests classified under those intents.
* **Tag selection mode** — decide what happens when multiple tags in the group match (see below).
* **Active** — toggle whether the group is live. Inactive groups are saved but don't tag incoming requests.
Click **Add tag** and choose what to create:
* **Tag** — a tag that classifies emails with the rules you define.
* **Fallback tag** — the tag Axon applies when no other tag in the group matches. Each group can have one fallback tag. You create and name it the same way as a regular tag.
Then add one or more rules to each tag. The **Add rule** picker groups the rule types by what they match:
**Match text in the mail body, subject, or attachments**
* **Against keywords** — match keywords or regular expressions in the mail text.
* **Against a reference list** — match values from a reference list column in the mail text.
**Match a value captured from the mail**
* **Against specific values** — compare the captured field value to values or ranges.
* **Against a reference list** — check if the captured field value exists in a reference list column.
Each rule also takes an **operator** that decides how the comparison is made — including negative ones, so you can tag on the *absence* of something. See [Rule operators](#rule-operators) below.
After the rules step, decide what value the tag should carry when its rules match. See [Static and dynamic tag values](#static-and-dynamic-tag-values) for the difference between the two options.
Browse and select up to 5 requests, then run a dry run to see which tags would be applied to each one. Requests that match no rules show **No tags matched**. Adjust your rules until the results look right.
## Rule operators
Every rule has an operator that decides how the comparison is made. The options depend on the rule type.
**Mail content, against keywords**
| Operator | Matches when the text… |
| -------------------------------------------------------------------- | --------------------------------------------------------------------------- |
| matches any of the keywords below | contains at least one keyword |
| matches all of the keywords below | contains every keyword |
| matches none of the keywords below | contains none of the keywords |
| matches any / all / none of the regular expressions below (advanced) | the same three options, using regular expressions instead of plain keywords |
**Against a reference list** (either mail content or a captured field)
| Operator | Matches when the value… |
| ----------------------------------------------------------- | ----------------------------- |
| equals any value in the reference list column below | appears in the column |
| does not equal any value in the reference list column below | does not appear in the column |
**Captured field, against specific values**
| Operator | Matches when the field… |
| --------------------------------------------- | ------------------------------------------------ |
| equals / does not equal | is, or isn't, the value you enter |
| contains / does not contain | includes, or doesn't include, the text you enter |
| is greater than / is greater than or equal to | is above the number you enter |
| is less than / is less than or equal to | is below the number you enter |
| is empty / is not empty | has no value captured, or has one |
The negative operators are useful for catching gaps rather than matches — for example tagging requests where a required reference is **is empty**, or where the subject **matches none of** your standard order keywords.
## Combining several rules on one tag
When a tag has more than one rule, an **And** / **Or** toggle appears between them:
* **And** (the default) — every rule must match before the tag applies.
* **Or** — the tag applies as soon as any one rule matches.
The choice applies to the whole tag, not to individual pairs of rules.
## Reference lists in tag rules
The two reference list rule types match against [reference data](/knowledge-base/administration/reference-data) that your organization has uploaded. When you add a reference list rule, you pick a **reference list** and then the **column** to match against.
The reference list picker only shows lists that fit the tag group's scope and your own area access:
* Lists uploaded to the **Default** area are available to every tag group.
* Lists uploaded to a specific [area](/knowledge-base/administration/areas) are available when the group is scoped to that area. Groups scoped to inboxes can use any list you have access to.
* Lists in areas you aren't assigned to are hidden.
Once you select a list, Axon loads that list's columns into the column picker. This works for lists in any area, including area-specific uploads outside the Default area.
If no reference lists match the group's scope, the picker is disabled and shows **No reference list options are configured for this group's inbox/area scope**. To fix this, upload a reference list to the Default area or to one of the areas in the group's scope. If you have access to reference data settings, use the link icon next to the **Reference list** label to open them directly.
## Static and dynamic tag values
Each tag has a value that Axon attaches to the request when its rules match. You pick how that value is set on the step titled **When those rules apply, what value should this tag have?**
* **Fixed value** — you type the exact text of the tag. Every request that matches the rules receives the same value. Use this when you want a stable label like `Key account` or `Large order`.
* **Dynamic value based on a reference list column** — Axon resolves the tag value at runtime by looking up a captured field in a reference list and reading a column from the matching row. Use this when the value depends on the request itself, for example tagging with the customer name or region tied to a customer number.
The **This is what you'll see** preview at the bottom of the step shows the tag pill exactly as it will appear on tagged requests.
### Configuring a dynamic tag value
Choose **Dynamic value based on a reference list column** and fill in:
1. **Take the value from** — the captured field on the request that identifies the row to look up, for example a customer number field.
2. **Look it up in a reference list and find the row where `` matches this column** — pick the reference list and the column in that list whose values should equal the captured field. Only reference lists that fit the tag group's scope and your area access are listed. If none match, the picker shows **No reference list options are configured for this group's inbox/area scope**. See [Reference lists in tag rules](#reference-lists-in-tag-rules) for the scoping rules.
3. **Use the value from this column as the tag name** — pick the column whose value from the matched row becomes the tag value.
While you're still configuring the tag, the preview uses placeholders in the format `{{ --> }}`. Once Axon evaluates the tag against a real request, the placeholder is replaced with the actual value from the matched row. If the lookup finds no matching row, the tag is not applied.
Dynamic tags appear in the group's tag list and the Tags page details view with a `{{ dynamic name }}` placeholder until Axon evaluates them against a request. In the **Dry run** step and on live requests, each dynamic tag pill shows the resolved value.
## Tag selection modes
When a request matches rules from more than one tag in a group, the tag selection mode decides which tags Axon applies:
* **Priority** — apply the highest-priority matching tag in the group. Drag tags in the list to set their priority order. The fallback tag doesn't take part in priority sorting.
* **Most matches** — apply the tag with the most matching rules.
* **All matching tags** — apply every tag that matches.
## When tags are applied
Tagging runs in two passes as a request is processed:
1. **At classification**, before extraction has run. Only tags whose rules look at mail text — keywords, regular expressions, and reference lists checked against the body, subject, or attachments — are evaluated here, so those tags can appear early.
2. **After processing**, once extraction and area are known. Every applicable group is evaluated again with the full picture. Tags with rules that depend on captured field values are resolved in this pass.
Tags are re-evaluated whenever a request is processed again — including when you **simulate** and the underlying values change. If a field a tag depends on gets a new value, the tag is recalculated against the current data rather than keeping its earlier result. The same applies after a reprocess or a configuration change to the tag group.
## Use cases
A few ways teams use tag groups:
* **Flag high-value products for attention.** Upload a reference list of your top-selling or strategic products, then add a *mail content reference list* rule matching against it. Requests mentioning those products arrive tagged, so the inbox surfaces them without anyone reading through first.
* **Segment by customer.** Tag requests by segment — key account, distributor, region — using a *captured field reference list* rule that looks up the customer number against a segment list. Pair it with a [dynamic tag value](#static-and-dynamic-tag-values) so the tag carries the segment name itself rather than a fixed label.
* **Catch urgent phrasing.** A *mail content keyword* rule matching words like `urgent`, `ASAP`, or `line down` flags requests that need to jump the queue. Set the group's selection mode to **All matching tags** so an urgent request still picks up its other tags too.
* **Spot incomplete requests.** Use the **is empty** operator on a field you always need — a PO number or requested delivery date — to tag requests that arrive missing it, before anyone starts working them.
* **Separate large orders.** A *captured field value* rule with **is greater than** on total quantity or order value tags orders above a threshold, so they can be routed for approval.
## Managing tag groups
The Tags page lists all tag groups with their **Group name**, **Scope**, **Tag selection mode**, **Last updated** time, and **Active** status. From here you can:
* **Expand a group** to view its tags and their rules.
* **Toggle a group active or inactive** using the switch in the Active column.
* **Edit a group** to change its configuration, tags, or rules.
* **Delete individual tags or entire groups**. You can also select multiple items and delete them in bulk.
* **Search** for groups and tags using the search bar in the toolbar.
## Example: flag large orders from key accounts
A tag group scoped to your Orders inbox could contain:
* A tag **Key account** with a *mail content reference list rule* that matches the sender against a reference list of strategic customer domains.
* A tag **Large order** with a *captured field value rule* that matches when the total quantity field exceeds a threshold.
* A **Fallback tag** named **Standard** for everything else.
With the tag selection mode set to **All matching tags**, a request from a strategic customer with a large order receives both tags. Your team can then prioritize it accordingly.
## Example: tag with the customer's region using a dynamic value
A tag group scoped to your Orders inbox could contain a single tag whose rules match any request that carries a customer number. On the tag value step, choose **Dynamic value based on a reference list column** and configure:
* **Take the value from** — the *Customer number* captured field.
* **Look it up in a reference list and find the row where Customer number matches this column** — reference list *Customers*, column *customer\_id*.
* **Use the value from this column as the tag name** — column *region*.
A request from a customer whose *Customers* row has `region = EMEA-North` is tagged `EMEA-North`. A request from a customer whose row has `region = APAC` is tagged `APAC`. You get one tag per region without having to create a separate tag for each.
## What's next
* [Navigate and organize the intent tree](/knowledge-base/axon/intent-tree)
* [Create and train custom intents](/knowledge-base/axon/create-custom-intents)
* [Manage reference data](/knowledge-base/administration/reference-data)