FAQs: Standard Modules and Fields

FAQs: Standard Modules and Fields

Understanding Standard Modules

What are standard modules?
Standard modules are built-in areas used to organize commonly required support data. They provide the default structure for records such as tickets, contacts, accounts, products, activities, contracts, and time entries.
For example, a support agent may use:
  1. Tickets to manage customer requests and issues
  2. Contacts to maintain customer information
  3. Accounts to group contacts by organization
  4. Products to track products connected to support cases
  5. Calls, Tasks, and Events to manage service activities
Can standard modules be customized for a specific business process?
Yes. Standard modules can be tailored by showing or hiding standard fields and by adding custom fields that capture business-specific information. Layouts can therefore contain both built-in fields and custom fields.

For example, a software support team might add a Product Version picklist and an Environment field to Tickets, while a financial services team may add a Referred By field to Contacts.
Which modules support custom fields?
Custom fields can be added to the following modules:
  1. Contracts
  2. Time Entry
  3. Agents
  4. Tickets
  5. Contacts
  6. Accounts
  7. Products
  8. Calls
  9. Tasks
  10. Events
Custom fields should be added only when they support a clear operational need, reporting requirement, or automation-related data point. Excessive fields can make forms difficult for agents to complete consistently.

Standard Fields

What are standard fields?
Standard fields are the default fields provided for common business information. Examples include company name and email address. They are included in standard module layouts to support routine record creation and management.
Can standard fields be removed from a layout?
Standard fields can be displayed or hidden according to organizational requirements. However, system-defined mandatory fields cannot be edited or deleted.

For example, fields such as Departments and Contact Name are system-mandated. They remain required elements of the system and cannot be removed through layout customization.
Do changes to a standard field affect only one department?
No, Changes made to standard fields in a layout apply across the organization. This should be considered before hiding a standard field because the change can affect teams outside the department making the configuration decision.
Can a standard field be edited or deleted?
Mandatory system-defined fields cannot be edited or deleted. Other standard fields can be managed by displaying or hiding them based on organizational requirements.

Custom Fields

What is the difference between a standard field and a custom field?
A standard field is provided by default for common service data. A custom field is created by the organization to capture information unique to its workflows.
For example:
  1. Email Address is a standard field in a customer-related module.
  2. Referred By can be a custom field created to identify the source that referred a customer.
Are custom fields shared across the organization?
Custom fields are specific to the department in which they are created. This allows departments to capture their own operational information without necessarily changing the data collection process for every other department.
What types of custom fields can be added?
Zoho Desk supports various custom field types, including:
  1. String fields
  2. Decimal fields
  3. Integer fields
  4. Currency fields
  5. Checkbox fields
  6. Date fields
  7. Date/Time fields
  8. Picklists
  9. Single-line fields
  10. Multiline fields
The selected field type should reflect the data being captured. For example, use a currency field for a contract amount, a checkbox for a yes-or-no condition, and a picklist where agents must select from a controlled list of values.
How should a team decide whether to create a custom field?
Create a custom field when the information is consistently needed for handling records, filtering records, reporting, or supporting a defined workflow. Avoid creating fields merely for occasional notes or information that belongs in an existing field.

For example, a Customer Tier picklist may be appropriate if routing or reporting depends on tier. A one-time explanation about a ticket is generally more appropriate in the ticket’s existing descriptive content than in a new field.

Managing Fields

How can the fields available in a module be reviewed?
  1. Navigate to Setup > Customization > Layouts and Fields.
  2. Click Fields List.
  3. Select the required module from the module dropdown.
The fields are listed alphabetically. The list provides key information, including:
  1. Field name
  2. Data type
  3. API name
  4. Layouts using the field
Why is the API name of a field important?
The Fields List displays each field’s API name alongside its label and data type. The API name helps distinguish fields at a technical or integration level, particularly where multiple fields have similar display labels.
Why might a layout not appear in the list of layouts using a field?
A layout that contains the field only in its Unused Fields section is not displayed as a layout using that field. The layout usage list reflects layouts where the field is actively placed for use.
How can a specific field be found when a module contains many fields?
Use the search box in the Fields List to filter by characters in the field name or to locate fields of a particular data type. This is particularly useful when a module has accumulated many custom fields over time.

Field Permissions and Data Protection

Can access be restricted for individual fields within a standard module?
Yes. Field permissions allow administrators to control whether agents can view or edit individual fields. This is useful when records include confidential customer or business information.

For example, if a Contact record contains bank account details, the field can be hidden for profiles that do not require access to that information.
What permission levels are available for fields?
A field can be configured with one of the following permissions:
  1. Read and Write - users can view and edit the field.
  2. Read Only - users can view the field but cannot change it.
  3. Don’t Show - users cannot view or edit the field.
How are field permissions configured?
  1. Navigate to Setup > Customization > Layouts and Fields.
  2. Click Field Permissions.
  3. Select the required module.
  4. Select the profile to configure.
  5. Set the required permission for each field.
  6. Click Save.

Field Dependencies

What are field dependencies?
Field dependencies create a parent-child relationship between picklist fields. The values shown in the child field depend on the selection made in the parent field.

For example, when a user selects a country, only the states associated with that country can be displayed. Similarly, selecting a product type can limit the issue options to those relevant to that product.
Which field type supports dependencies?
Dependencies can be created using Pick List fields. Both the parent and child values should be designed carefully so that the available choices remain relevant and manageable for agents.
How are field dependencies created?
Navigate to Setup > Customization > Layouts and Fields.
Click Fields Dependencies.
Select the required module and department.
Click Add New Dependency.
Define the parent picklist field, child picklist field, and valid value mappings.
Save the dependency configuration.

Why should field dependencies be used instead of one long picklist?
Dependencies reduce irrelevant choices and help agents select consistent values. They are especially useful where the valid secondary option depends on an earlier selection.

For instance, a single Issue Type list containing every issue for every product may be difficult to use. A Product Type parent field with an issue-specific child picklist makes the form more accurate and easier to complete.

Configuration Considerations

How can field design prevent poor-quality support data?
Use the appropriate field type, make essential information mandatory where supported, restrict sensitive fields through permissions, and use picklist dependencies when one selection determines another. A well-designed layout reduces inconsistent entries and avoids forcing agents to interpret ambiguous free-text values.
What is the risk of adding too many custom fields?
Too many fields can make record forms difficult to complete, reduce data consistency, and obscure the information agents need during active support work. Review existing fields before adding new ones and use the Fields List to identify similar or duplicate fields.
Should a field be hidden or set to read-only?
Use Don’t Show when a profile should not know the field exists or must not access its value. Use Read Only when the profile needs the information for context but should not be able to change it.

For example, a support lead may need to edit a customer classification field, while agents may only need to view it to prioritize service correctly.