FAQs: Fields and Properties | Zoho Desk

FAQs: Fields and Properties

Field Fundamentals

What are fields?
Fields capture information in Zoho Desk modules, including Tickets, Contacts, Accounts, Products, Activities, and other records. Each field is designed for a particular type of information, such as a date, selected value, short text, or longer description.

For example, a Ticket may use fields for Subject, Contact Name, Status, Product, Purchase Date, and an internal Order Number.
What field types are available?
Fields use data types appropriate to the information being stored. Available examples include:
  1. Date
  2. Date/Time
  3. Picklist
  4. Single-line text
  5. Multi-line text
  6. String
  7. Decimal
  8. Integer
  9. Currency
  10. Checkbox
The appropriate type should be selected based on how the value will be collected and used. For example, use a Date field for a purchase date, a Currency field for a charge amount, and a Picklist for a controlled set of issue categories.
Are fields part of layouts?
Yes. A layout contains both standard fields and custom fields. The layout determines how the fields are organized for a module and can control whether they are shown, read-only, or required.

A well-designed layout presents only the fields needed for the specific support process, rather than exposing every available field to every user.

Standard Fields

What are standard fields?
Standard fields are built-in fields provided for common business information. Examples include Company Name and Email Address.

Organizations can show or hide standard fields based on their operational needs, subject to the restrictions that apply to mandatory system-defined fields.
Can standard fields be edited or deleted?
Mandatory system-defined standard fields cannot be edited or deleted. Examples include Departments and Contact Name.

Before changing the visibility or configuration of other standard fields, consider the impact across the organization.
Does changing a standard field affect one layout or the entire organization?
Changes made to standard fields in a layout apply across the organization. Administrators should therefore evaluate downstream effects before modifying standard-field behavior.

For example, hiding a standard field to simplify one team’s form may affect how that field is available elsewhere in the organization.

Custom Fields

What are custom fields?
Custom fields are fields created to capture information specific to an organization’s support process or industry. They supplement standard fields when the default data model does not include the information required by the team.

For example, an organization can create a Referred By custom field to record how a customer was referred.
Are custom fields shared across all departments?
No, Custom fields are specific to the department in which they are created.

For example, a Billing department can create a custom Invoice Reference field without automatically making that field available in a Technical Support department. If multiple departments need the same information, field configuration should be reviewed in each relevant department.
Which modules can use custom fields?
Custom fields can be added to:
  1. Contracts
  2. Time Entry
  3. Agents
  4. Tickets
  5. Contacts
  6. Accounts
  7. Products
  8. Calls
  9. Tasks
  10. Events
How should the right custom-field type be selected?
Choose the type that most closely matches the intended value and how users should enter it:
  1. Use Single-line text for a short identifier, such as an order number.
  2. Use Multi-line text for detailed notes or an issue description.
  3. Use Picklist when users must select from approved categories.
  4. Use Checkbox for a yes/no confirmation.
  5. Use Integer or Decimal for numeric quantities.
  6. Use Currency for monetary values.
  7. Use Date or Date/Time for time-based information.
For example, use a Picklist for Issue Category so agents select consistent values such as Billing, Delivery, or Product Defect instead of entering varied free-text descriptions.

Reviewing and Managing Fields

Where can administrators view all fields in a module?
Support Administrators can open the field inventory from:
  1. Navigate to Setup > Customization > Layouts and Fields.
  2. Select Fields List.
  3. Choose the required module from the Module drop-down list.
The fields for the selected module are displayed alphabetically.
What information is available in the Fields List?
The Fields List provides a consolidated view of fields in the selected module, including:
  1. Field name
  2. Data type
  3. API name
  4. Layouts that use the field
Custom fields are marked with a custom-field indicator. Administrators can also search the list to locate a specific field or filter through a long field inventory.
Why is a field not shown as used in a layout?
Layouts that contain the field only in their Unused Fields section are not displayed in the field’s layout-usage information. A field must be actively included in the layout to be shown as used there.
Why should field inventories be reviewed regularly?
Custom fields can accumulate over time as products, teams, and workflows change. A field inventory helps administrators identify:
  1. Duplicate or overlapping fields
  2. Fields with incorrect data types
  3. Fields no longer used in active layouts
  4. Fields containing sensitive information
  5. Layouts where a field is currently used
For example, two fields named Order ID and Order Number may appear similar but be used differently. Reviewing their API names, data types, and layout usage helps determine whether both are necessary.

Field Permissions and Security

How can field permissions be set for a profile?
  1. Navigate to Setup > Customization > Layouts and Fields.
  2. Select Fields Permissions.
  3. Choose the required Module.
  4. Choose the required Profile.
  5. Set each relevant field to:
    1. Read and Write
    2. Read Only
    3. Don’t Show
  6. Click Save.
Should field permissions or layout configuration be used to control access?
Use layouts to organize which fields are relevant to a process and to manage field behavior within that process. Use Field Permissions to restrict a profile’s ability to view or edit a field within a module.

For example, a layout can include an Approval Reference field because the field is relevant to an escalation workflow. Field Permissions can then make it read-only for support agents while allowing an authorized profile to update it.
What should be checked before hiding a field?
Before setting a field to Don’t Show, verify:
  1. The field is not mandatory.
  2. The profile does not need the value to perform its work.
  3. The field is not required for data entry in the profile’s workflow.
  4. The correct module and profile have been selected.
  5. The field is not being hidden unintentionally from users who need access.

Field Design Practices

How can unnecessary custom fields be avoided?
Create a custom field only when the information is required for a real support, reporting, or workflow purpose. Before creating one, check whether:
  1. An existing standard field already captures the information.
  2. An existing custom field can be reused.
  3. A Picklist would produce more consistent data than free-text entry.
  4. The information is needed in more than one department.
  5. The field should be visible, required, or restricted for each relevant profile.
Why is a Picklist often preferable to a text field for categorization?
A Picklist limits users to defined options, which improves consistency. This is especially useful for categories that agents may otherwise enter with different spellings or terminology.

For example, a free-text category might result in “Refund,” “refund request,” and “Billing refund.” A Picklist can standardize those entries into a single Refund option.