FAQs: Custom Fields | Zoho Desk

FAQs: Custom Fields

Custom Field Basics

What is a custom field?
A custom field captures information that is specific to an organization’s support process and is not covered by the built-in fields. It can be added to a module layout to collect structured information from agents or customers.

For example, a technical-support team can add a Device Name field, while a sales-support team can use a Referred By field to record the source that introduced a customer.
Which modules support custom fields?
Custom fields can be added to the following modules:
  1. Tickets
  2. Contacts
  3. Accounts
  4. Products
  5. Contracts
  6. Agents
  7. Time Entry
  8. Calls
  9. Tasks
  10. Events
Custom-field design should be reviewed separately for each module because the data needed for a Ticket may differ substantially from the data needed for a Contact or Task.

Creating and Placing Custom Fields

How can a custom field be added to a layout?
  1. Navigate to Setup > Customization > Layouts and Fields.
  2. Open Fields List.
  3. Select the required module.
  4. Click Create or Edit Fields.
  5. Select the correct department and layout.
  6. Drag the required field type into the layout.
  7. Enter the field properties.
  8. Click Add.
  9. Save the layout.
Select the department and layout carefully before creating the field. Since custom fields are department-specific, creating the field in the wrong department may prevent it from being available where the intended team works.
Which field type should be used for a new custom field?
Select the field type according to the type of information being captured. Zoho Desk supports field types including text, number, picklist, currency, checkbox, date, and date/time fields.

A practical selection approach is:
  1. Single-line text or string for short values, such as a device serial number.
  2. Multi-line text for detailed internal information.
  3. Picklist for controlled categories or statuses.
  4. Checkbox for a yes/no value.
  5. Integer or decimal for quantities.
  6. Currency for monetary amounts.
  7. Date or Date/Time for time-specific information.
For example, use a Picklist for Issue Category when agents should select from defined values such as Billing, Delivery, and Product Defect. This produces more consistent data than an unrestricted text field.
Can an existing custom field be added to more than one layout?
Yes. An existing field can be added to multiple layouts when the same information is relevant across different processes.

For example, a telecommunications organization may use Device Name in both a device-activation layout and a service-interruption layout. Reusing the same field supports consistent data collection and reporting.

When the field is added to another layout, it is placed in the corresponding section of that department’s layout. If that section does not exist, the field is placed in the first section of the form.



Should a separate field be created for every layout?
No, Create a separate field only when the data itself is different. Reuse an existing field when different layouts need to capture the same value.

For example, if several Ticket layouts require a customer’s Order Number, adding the same existing field to each layout is generally more consistent than creating separate versions of that field for each layout.

Managing Field Values and Data Quality

When should a Picklist be used instead of a text field?
Use a Picklist when users should select from a controlled, repeatable set of values. This is particularly important for values used in reporting, routing, or categorization.

For example, a free-text field may produce entries such as “refund,” “Refund request,” and “billing refund.” A Picklist can standardize all of those under a single Refund value.
Can Picklist values be replaced in records that already use them?
Yes. When replacing an existing Picklist value, the replacement is reflected automatically in records that already contain the old value. Individual records do not need to be updated manually.

For example, if Hardware Issue is replaced with Device Issue, existing records using Hardware Issue are updated to use Device Issue. The affected records’ modified date and time are also updated.
Is replacing a Picklist value the same as renaming it?
No, Replacing a value updates the value in records where it is already used. Administrators should treat this as a data change, not merely a label adjustment.

Before replacing a value, confirm that the target value represents the same business meaning. Replacing Refund Request with Billing Query, for example, could affect the accuracy of historical categorization.
How can Picklist values be replaced?
  1. Navigate to Setup > Customization > Layouts and Fields.
  2. Open Fields List.
  3. Select the required module.
  4. Click Create or Edit Fields.
  5. Confirm the appropriate department and layout.
  6. Open the field settings for the required Picklist.
  7. Select Replace Values.
  8. Choose:
    1. The existing value to replace.
    2. The new value to use instead.
  9. Click Replace.
  10. Save the layout.

Dependent Fields

What are field dependencies?
Field dependencies create a parent-child relationship between two Picklist fields. The values displayed in the child field depend on the value selected in the parent field.

For example, a Country field can be the parent and a State field can be the child. After a user selects a country, only the relevant states are presented.
What business scenarios are suitable for dependent fields?
Dependent fields are useful when a second choice should be narrowed by an earlier choice. Common examples include:
  1. Main department → sub-department
  2. Product type → issue type
  3. Country → state or region
  4. Service category → specific request type
For example, selecting Mobile Device as a product type can show mobile-specific issue values, while selecting Internet Service can show connectivity-related issue values.
How can field dependencies be configured?
  1. Navigate to Setup > Customization > Layouts and Fields.
  2. Open Fields Dependencies.
  3. Select the required module and department.
  4. Click Add New Dependency.
  5. Select:
    1. The Parent Field
    2. The Child Field
  6. Click Next.
  7. Select the child values that should be available for each parent value.
  8. Click Save Field Dependency.
When users create a record, the child-field options are populated according to the selected parent value.
Can any field type be used for a dependency?
No, Field dependencies are created using Picklist data-type fields. The parent and child fields should therefore be designed as Picklists before the dependency is configured.

Finding and Reviewing Custom Fields

How can all fields for a module be reviewed?
  1. Navigate to Setup > Customization > Layouts and Fields.
  2. Open Fields List.
  3. Choose the required module from the module drop-down list.
The fields for that module are listed alphabetically. The list includes the field name, data type, API name, and the layouts that actively use the field.
Can a specific custom field be found quickly?
Yes. Use the search box in the Fields List to locate a particular field or identify fields of a given data type. Custom fields are also visually marked in the list.

This is useful when reviewing a large configuration for duplicate fields, outdated fields, or sensitive fields that require permission controls.
Why is a field not listed as used by a layout?
Layouts that contain the field only in their Unused Fields section are not included in the field’s layout-usage information. To be identified as used, the field must be actively placed on the layout.
How should unused custom fields be reviewed before removal?
Review the field’s module, department, data type, API name, and active layout usage before deciding whether it is no longer needed. A field that is not on an active layout may still be relevant to an internal process or historical data review.

Avoid creating replacement fields with slightly different labels unless the underlying data requirement has changed. Reusing a correctly designed field generally improves reporting consistency.

Search Considerations

Can custom fields be included in record searches?
Yes. Search fields can be customized for Tickets, Contacts, Accounts, and Knowledge Base records. By default, all fields are selected for search; administrators can instead specify the fields whose values should be searched.

For example, a support team may choose to search Tickets by Subject, Order Number, and Device Name rather than searching every available field.
Are there limits on the number of searchable fields?
Yes. When specific search fields are selected:
  1. A maximum of 10 fields per module can be selected for Tickets, Contacts, Accounts, and Knowledge Base.
  2. A maximum of 6 fields can be selected for Contracts, Products, Calls, Events, and Tasks.
Search Field settings are organization-level settings and apply across all departments in Zoho Desk.
How can searchable fields be configured?
  1. Navigate to Setup > Customization > Layouts and Fields.
  2. Open Search Fields.
  3. Select the required module.
  4. Select Specific Fields.
  5. Choose the fields whose values should be searchable.
  6. Click Save.

Design and Governance

What should be decided before creating a custom field?
Before creating a field, confirm:
  1. Business purpose - Identify the support, reporting, or workflow need the field serves.
  2. Correct module and department - Confirm where the information belongs and which department needs it.
  3. Appropriate data type - Select a type that supports consistent entry and reliable use.
  4. Field visibility - Decide which profiles need editable, read-only, or no access.
  5. Layout placement - Add the field only to layouts where users need to enter or review it.
  6. Search need - Determine whether agents must be able to find records using the field’s value.
  7. Reuse - Check whether an existing field already captures the information.
What is the risk of creating too many custom fields?
Too many fields can make layouts difficult to complete, create inconsistent data, complicate permission management, and make it harder to identify the correct field for reporting or search.

For example, if separate teams create Serial No., Serial Number, and Device Serial fields, agents may enter the same information in different places. A single governed field added to the relevant layouts is typically easier to maintain.