> For the complete documentation index, see [llms.txt](https://limechatai.gitbook.io/limechat-product-guide/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://limechatai.gitbook.io/limechat-product-guide/helpdesk/settings/custom-contact-fields.md). # Custom Contact Fields ### Overview Hierarchical Custom Contact Fields help teams capture customer/contact information in a structured way by showing fields or options based on previous selections. This hierarchy is created using **dropdown-based fields**, because conditional dependency works only when the system has a fixed set of selectable parent values. Instead of showing agents one long list of customer attributes, the system shows only the relevant next-level dropdown/options based on the previous selection. **Example:** Customer Type → High Intent Buyer → Product Interested In / Budget Range / Purchase Timeline This improves customer profiling, segmentation, personalization, routing, reporting, automation, and long-term CRM hygiene. Unlike custom ticket fields, which are usually used to capture issue-specific or conversation-specific details, custom contact fields are used to capture information about the customer. These fields stay associated with the contact and can be reused across future conversations, campaigns, automations, and reports. *** ### Key Capability Hierarchical Custom Contact Fields allow teams to: * Capture structured customer information * Create cleaner customer profiles * Avoid irrelevant fields/options being shown to agents * Improve customer segmentation * Power better personalization in future conversations * Enable smarter routing and automation * Maintain reusable customer-level data across tickets * Improve reporting on customer attributes and cohorts *** ### Important Nuance: Hierarchy Works Only With Dropdown-Based Fields The hierarchical structure can only be configured using **dropdown-based custom fields**, such as: * Single Select Dropdown * Multi Select Dropdown, if supported for dependency logic This is because a hierarchy requires a clear parent-child relationship. For example: Customer Type = High Intent Buyer\ Then show only relevant next-level values such as: * Product Interested In * Budget Range * Purchase Timeline This dependency works because the parent value is selected from a predefined list. For non-dropdown fields like text, number, date, or free-form input, the system cannot reliably create a structured conditional relationship because the input is not predefined. So, while other field types may be used for capturing information independently, the actual hierarchical dependency should be created using dropdown-based fields. *** ### How It Works A parent dropdown value controls which child dropdown/options appear next. For example, if the agent selects a specific customer type, only the relevant next-level dropdown options are shown. This ensures agents capture only the information that is relevant to that customer. *** ### Example 1: Dropdown-Based Hierarchy **Level 1: Customer Type** * New Customer * Existing Customer * High Intent Buyer * VIP Customer * Distributor / Partner **Level 2: Based on Customer Type** If **High Intent Buyer** is selected, show relevant options such as: * Product Interested In * Budget Range * Purchase Timeline If **Existing Customer** is selected, show relevant options such as: * Last Purchase Category * Repeat Purchase Intent * Preferred Communication Channel If **Distributor / Partner** is selected, show relevant options such as: * Business Type * Region * Monthly Order Volume *** ### Example 2: Three-Level Dropdown Hierarchy **Level 1: Customer Segment** * Retail Customer * B2B Customer * Influencer * Partner **Level 2: If B2B Customer is selected** * Business Category * Expected Monthly Volume * Region **Level 3: If Region is selected** Show only relevant city/territory options based on the selected region. Example: If **Region = North India**, show: * Delhi NCR * Punjab * Haryana * Uttar Pradesh If **Region = South India**, show: * Karnataka * Tamil Nadu * Kerala * Telangana This allows the team to capture structured customer information using predefined values at each level. *** ### Why Conditional Dependency Matters Without dependency, hierarchy becomes only a visual grouping layer. The real value comes when the selected parent dropdown value controls what the agent sees next. For contact fields, this is especially important because the data is not just used for one ticket. It can directly impact customer segmentation, future campaigns, automation rules, customer journeys, and reporting. For example: If an agent marks a customer as **High Intent Buyer**, the next dropdown should help capture buying intent, product interest, budget, or timeline. But if the customer is marked as **Existing Customer**, the next dropdown should capture repeat purchase intent, last purchase category, or preferred channel. This avoids irrelevant data capture and keeps customer profiles clean. *** ### Steps to Create Hierarchical Custom Contact Fields A detailed video walkthrough is attached for reference: **Hierarchical Custom Fields Guide** #### Step 1: Go to Custom Fields Navigate to: **Settings → Custom Fields → Create Custom Field** Select the custom field category as **Contact Field**, if the system provides separate options for ticket fields and contact fields.
*** #### Step 2: Select a Dropdown-Based Field Select a dropdown-based field type. Recommended: **Single Select Dropdown** This becomes the first level of the hierarchy. Example: **Customer Type**
*** #### Step 3: Add First-Level Options Define the options for the first dropdown. Example: * New Customer * Existing Customer * High Intent Buyer * VIP Customer * Partner / Distributor These values will control which sub-level dropdown/options appear next. *** #### Step 4: Add a Sub-Level Dropdown After adding the first-level options, start adding sub-levels. The sub-level should also be a dropdown-based field so that a proper conditional relationship can be created. Give the sub-level dropdown a name and define when it should appear based on the selection made in the level above. Example: Show **Purchase Intent Details** only when **Customer Type = High Intent Buyer**. *** #### Step 5: Define Conditional Visibility For every sub-level dropdown, define the condition based on the parent dropdown selection. This ensures that the next dropdown appears only when it is relevant. Example: Show **Purchase Timeline** only when **Customer Type = High Intent Buyer**. Show **Monthly Order Volume** only when **Customer Type = Distributor / Partner**. *** #### Step 6: Add Another Dropdown Level You can continue adding another dropdown-based field and define further dependency. This allows you to create a third-level hierarchy. Example: Customer Type → High Intent Buyer → Product Category → Specific Product Interest *** #### Step 7: Configure Level 3 Dependencies Define when the third-level dropdown or options should appear based on the second-level selection. Example: If **Product Category = Skincare**, show: * Moisturizer * Sunscreen * Serum * Face Wash If **Product Category = Haircare**, show: * Shampoo * Conditioner * Hair Oil * Hair Serum These fields are interdependent. Each dropdown appears based on the condition defined at the level above. *** #### Step 8: Save and Test After saving, test the setup on a customer/contact profile. Check that: * The first-level dropdown appears correctly * The right sub-level dropdown appears based on the selected value * Irrelevant dropdowns/options remain hidden * The data is saved correctly on the contact profile * The same contact data is available across future tickets/conversations * The fields can be used in segmentation, reporting, routing, or automation where applicable
*** ### Best Practices * Use hierarchy only where dropdown-based dependency is required. * Use contact fields only for customer-level information, not ticket-specific issues. * Keep the hierarchy simple and easy to understand. * Use predefined dropdown values wherever possible to maintain clean and reportable data. * Avoid using free-text fields for hierarchical relationships. * Ensure each child dropdown is relevant to the selected parent value. * Avoid duplicate fields between ticket fields and contact fields. * Use contact fields for information that should persist across future conversations. * Review field usage regularly and remove fields that are not being used. * Ensure field names and dropdown values are clear and agent-friendly. *** ### Key Notes * Hierarchical dependency works only with dropdown-based fields. * Dropdown values create the parent-child relationship needed for conditional visibility. * Non-dropdown fields like text, number, and date fields can capture information, but they should not be used to create hierarchy. * Custom contact fields are stored at the customer/contact level. * The data captured can be reused across multiple tickets or conversations. * These fields are useful for segmentation, personalization, routing, automation, and customer reporting. * Contact fields should not be used for temporary issue-level information. * Incorrect or overly broad contact fields can create long-term data quality issues because this data persists at the customer level. * Teams should be careful while updating contact-level fields because they may impact future customer journeys, campaigns, or automations. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## 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, and the optional `goal` query parameter: ``` GET https://limechatai.gitbook.io/limechat-product-guide/helpdesk/settings/custom-contact-fields.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. 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.