# Hierarchical Custom Fields

### Overview

Hierarchical Custom Fields help teams capture ticket/customer information in a structured way by showing fields or options based on previous selections.

Instead of showing agents one long list of values, the system shows only the relevant next-level fields/options.

**Example:**\
`Order Issue → Delivery → Delayed / Lost / Wrong Address`

This improves data quality, agent efficiency, reporting, routing, SLA tracking, and automation.

### Key Capabilities

| Capability                    | Description                                                                          |
| ----------------------------- | ------------------------------------------------------------------------------------ |
| 3-level hierarchy             | Supports up to three levels of dependent fields.                                     |
| Conditional dependency        | Lower-level fields/options appear based on the parent selection.                     |
| Dropdown-driven parent fields | Parent fields are dropdown-based because the selected value controls the next level. |
| Flexible dependent fields     | Lower levels can be dropdown, text box, date, number, comment field, etc.            |
| Cleaner reporting             | Structured values make analytics more accurate.                                      |

### How It Works

| Level   | Field Example                     | Field Type Example              |
| ------- | --------------------------------- | ------------------------------- |
| Level 1 | Issue Type                        | Dropdown                        |
| Level 2 | Issue Category                    | Dropdown                        |
| Level 3 | Issue Detail / Additional Details | Dropdown / Text / Date / Number |

#### Example 1: Dropdown-based hierarchy

| Level 1     | Level 2  | Level 3       |
| ----------- | -------- | ------------- |
| Order Issue | Delivery | Delayed       |
| Order Issue | Delivery | Lost          |
| Order Issue | Delivery | Wrong Address |

#### Example 2: Third level as text box

| Level 1       | Level 2           | Level 3               |
| ------------- | ----------------- | --------------------- |
| Payment Issue | Refund            | Add refund details    |
| Complaint     | Escalation Needed | Add escalation reason |
| Product Issue | Damaged Item      | Add damage comments   |

### Why Conditional Dependency Matters

Without dependency, hierarchy becomes only a visual grouping layer.

The real value comes when the selected parent value controls what the agent sees next.

| Without dependency                        | With dependency                                    |
| ----------------------------------------- | -------------------------------------------------- |
| Agents see all options together           | Agents see only relevant options                   |
| Higher chance of wrong tagging            | Cleaner and more accurate tagging                  |
| Reporting becomes noisy                   | Reporting becomes structured                       |
| Harder for agents to pick the right value | Faster and easier field selection                  |
| Limited workflow value                    | Useful for routing, SLA, automation, and analytics |

## Steps to Create Hierarchical Custom Fields

A detailed video walkthrough is attached for reference: [Hierarchical Custom Fields Guide](https://limechat.clueso.io/share/dcd4ef70-0011-4b8a-b830-7925735e6911)

1. **Step 1: Go to Custom Fields**
   1. Navigate to: **Settings → Custom Fields → Create Custom Field**
2. **Step 2: Select Single-Select Dropdown**
   1. Select **Single Select Dropdown** as the field type. This becomes the first level of the hierarchy.
3. **Step 3: Add First-Level Options**
   1. Define the options for the first dropdown.:

These values will control which sub-level fields appear next.

4. **Step 4: Add a Sub-Level Field**
   1. After adding the first-level options, start adding sub-levels.
   2. The sub-level field can be of any supported field type.
   3. Give the sub-level field a name and define when it should appear based on the selection made in the level above.
5. **Step 5: Define Conditional Visibility**
   1. For every sub-level field, define the condition based on the parent field selection.

This ensures that the next field appears only when it is relevant.

6. **Step 6: Add Another Field / Level**
   1. You can continue adding another field and select the required data field type.
   2. If you select **Single Select Dropdown** again, you can add another sub-level under it.
   3. This allows you to create a third-level field.

Example:

| Level 1       | Level 2           | Level 3                        |
| ------------- | ----------------- | ------------------------------ |
| Order Issue   | Delivery          | Delayed / Lost / Wrong Address |
| Payment Issue | Refund            | Refund Pending / Refund Failed |
| Complaint     | Escalation Needed | Add escalation reason          |

7. **Step 7: Configure Level 3 Dependencies**
   1. Define when the third-level field or options should appear based on the second-level selection.

Example:

| If Level 2 selection is | Show Level 3                                    |
| ----------------------- | ----------------------------------------------- |
| Delivery                | Delayed, Lost, Wrong Address                    |
| Refund                  | Refund Pending, Refund Failed, Duplicate Refund |
| Escalation Needed       | Text box: Add escalation reason                 |

These fields are interdependent. Each field appears based on the condition defined at the level above.

8. **Step 8: Save and Test**
   1. After saving, test the setup on a ticket/customer profile.

<table><thead><tr><th width="260.44921875">Check</th><th>Expected Behaviour</th></tr></thead><tbody><tr><td>Level 1 dropdown appears</td><td>Agent can select the parent value</td></tr><tr><td>Level 2 appears conditionally</td><td>Only relevant field/options are shown</td></tr><tr><td>Level 3 appears conditionally</td><td>Correct field/options appear based on Level 2</td></tr><tr><td>Irrelevant fields are hidden</td><td>Agents do not see unrelated fields</td></tr><tr><td>Values are saved correctly</td><td>Selected values are stored on the record</td></tr></tbody></table>

<figure><img src="/files/spevLelG1krnwLkuCGPk" alt=""><figcaption></figcaption></figure>

### Best Practices

| Best Practice                          | Why                                  |
| -------------------------------------- | ------------------------------------ |
| Keep hierarchy simple                  | Too many values can slow agents down |
| Use dropdowns for standard values      | Better for reporting and automation  |
| Use text fields only for extra context | Avoids messy reporting               |
| Avoid duplicate categories             | Reduces confusion                    |
| Plan reporting before setup            | Ensures the hierarchy is useful      |
| Train agents on usage                  | Improves consistency                 |

### Key Notes

| Item                       | Note                                                |
| -------------------------- | --------------------------------------------------- |
| Hierarchy depth            | Supports up to three levels                         |
| Parent field               | Should be single-select dropdown                    |
| Dependency                 | Lower-level fields appear based on parent selection |
| Existing reports/workflows | May need updates to use the new field structure     |

### Summary

Hierarchical Custom Fields help teams capture cleaner and more meaningful ticket/customer data.

They are useful when teams need structured categorization, better reporting, improved routing, SLA logic, automation, and internal tracking.

The core principle is simple:

> Lower-level fields should appear based on the parent selection, so agents only capture relevant and accurate information.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://limechatai.gitbook.io/limechat-product-guide/helpdesk/settings/custom-ticket-fields-setup-guide/hierarchical-custom-fields.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.