FAQs: Encrypting Custom Fields | Zoho Desk

FAQs: Encrypting Custom Fields

Encryption Scope and Purpose

Which help desk data is encrypted by default?
Zoho Desk encrypts data while it is transmitted and during backups using TLS 1.2. Sensitive information including passwords, authentication tokens, ticket conversations, and attachments, which is also protected by default. This protection is intended to reduce the risk of unauthorized access, disclosure, or alteration of service data.
Why should custom help desk fields be encrypted?
Custom-field encryption provides an additional protection layer for information that an organization classifies as particularly sensitive. Typical candidates include credit card numbers and personally identifiable information (PII) captured in custom fields.

For example, a support team that collects a customer’s government-issued identifier or payment-related reference in a Ticket custom field should evaluate whether that field requires additional protection beyond ordinary field access controls.
Does encrypting a custom field replace field permissions?
No, Encryption and field permissions address different security needs:
  1. Encryption protects sensitive custom-field data with an additional security layer.
  2. Field permissions determine which agent profiles can view or edit a field.
For example, a bank-account-detail field may be encrypted while also being set to Don’t Show for general agents and Read Only for a restricted finance profile. Encryption should not be treated as a substitute for limiting access.
Is custom-field encryption only relevant for payment information?
No, Payment information is one example, but encryption can also be appropriate for any custom field that stores sensitive personal or business data. Organizations should assess fields that contain PII or information subject to internal security, privacy, or regulatory requirements.

Examples may include:
  1. Government or tax identifiers
  2. Customer financial details
  3. Sensitive contractual references
  4. Personally identifying customer attributes

Access Control and Permissions

Can every agent access encrypted custom-field data?
Access should be controlled through the organization’s field-permission configuration. Field permissions can be assigned by module and profile, allowing administrators to choose one of these levels for a field:
  1. Read and Write - the user can view and edit the field.
  2. Read Only - the user can view but cannot edit the field.
  3. Don’t Show - the field is neither visible nor editable.
This allows an organization to restrict sensitive fields to only the profiles that require access.
Can a sensitive field be hidden from some support agents?
Yes. An administrator can set a field to Don’t Show for selected profiles. This prevents those users from seeing or editing the field in the applicable module.

For instance, a Contact custom field used for sensitive customer financial information can be visible to a specialized billing team while remaining hidden from frontline support agents.
Can a sensitive field be visible but protected from changes?
 Yes. Configure the field as Read Only for the relevant profile. This is appropriate when agents need information to support a customer but should not be able to modify it.

For example, a support agent may need to confirm an approved customer classification while only a compliance team is permitted to update that classification.

Configuration Considerations

Where are custom fields managed?
Custom fields are managed from Setup, under Customization > Layouts and Fields. Administrators can review field details through the Fields List, including:
  1. Field name
  2. Data type
  3. API name
  4. Layouts in which the field is used
This inventory is useful when identifying fields that may hold sensitive information and require tighter controls.
Are custom fields shared across every department?
No, Custom fields are specific to the department in which they are created. A security review should therefore account for each department separately.

For example, a custom field created for a Billing department’s tickets may not automatically be available in a Technical Support department. Administrators should review the fields and permissions in every department where sensitive data is collected.
Can a mandatory custom field be hidden for a restricted profile?
No, A mandatory field cannot be set to Read Only or Don’t Show through field permissions. If a field must be concealed from certain users, evaluate whether it should be mandatory for the same record workflow.

Privacy and Compliance

Does custom-field encryption support privacy and compliance practices?
Custom-field encryption can support an organization’s privacy and security practices by adding protection for sensitive information that it chooses to collect. It should be combined with appropriate access controls, profile-based permissions, and data-handling policies.

Encryption alone does not determine whether collecting a particular data element is appropriate. Organizations should only capture information needed for their support process and protect it according to applicable internal and legal requirements.
Can customer data be exported after using protected custom fields?
Zoho Desk provides export options for service data by module, with exports presented in CSV format. Because exported data may contain sensitive values, organizations should apply strict internal controls to exported files, including limiting who can initiate exports and who can access the resulting data.


Operational Planning

Which modules can contain custom fields that may need protection?
Custom fields can be added in the following modules:
  1. Contracts
  2. Time Entry
  3. Agents
  4. Tickets
  5. Contacts
  6. Accounts
  7. Products
  8. Calls
  9. Tasks
  10. Events
A practical security review should prioritize modules most likely to contain customer, financial, contractual, or employee-related data.
What should be reviewed before placing sensitive information in a custom field?
Before collecting sensitive data in a custom field, confirm:
  1. Business necessity - Determine whether the data is genuinely required to resolve or manage support work.
  2. Department placement - Verify the correct department because custom fields are department-specific.
  3. Field access - Define which profiles require read/write, read-only, or no access.
  4. Mandatory-field impact - Ensure the field does not create an unavoidable data-entry requirement for profiles that should not see it.
  5. Export handling - Consider who can access exported data and how exported files will be protected.
  6. Layout validation - Preview the layout by profile to confirm that sensitive fields are exposed only where intended.