Admin Pro Tip: Custom Fields - How to Avoid "Field Sprawl"

When optimising Zendesk instances, a recurring phenomenon often appears across company sizes and industries: "Field Sprawl". It is the quiet, gradual growth in custom fields that can, over time, turn an otherwise manageable ticket form into an unmanageable set-up. It typically starts with good intentions: "We need one more field to track X" or "Can we add a dropdown for Y?". Over time, the result can be a form so long that you have to scroll to find basic information, and reporting marked by empty or irrelevant data.
This article serves as a guide to regaining control through experience, strategies and concrete tools for identifying, prioritising and cleaning up custom fields. The goal is both to remove unnecessary fields and to establish a culture and process that ensures every field in Zendesk has a clear purpose and an active role in the support processes.

When Enough is Enough - How Many Fields are Too Many?

There is no magic number for when the number of fields becomes a problem. The limit is not about a specific number, but about the experience of when the fields begin to do more harm than good.

There are, however, a number of clear symptoms of a "Field Sprawl" problem:

• Agent confusion: If agents often ask "What should go in this field?" or "Why is the field important?", it is a clear warning sign. A good ticket form should be intuitive and guide the agent rather than create uncertainty.
• Performance problems: Many fields, especially complex fields with many dependencies, can make the ticket view slower. When a ticket is opened, Zendesk has to fetch and render all the fields, which can be noticeable at scale.
• Reporting nightmare: In Explore, a very long list of fields can appear, where many are empty, contain meaningless data or duplicate information from other fields. This makes relevant data points harder to find and increases the risk of errors in reports.
• Maintenance burden: When processes change, many fields have to be reviewed to update descriptions, dropdown values or dependencies, which is time-consuming and increases the risk of errors.

A practical rule of thumb is the "fold rule": Can an agent see all the essential fields that need to be filled in to solve a standard case, without having to scroll on an average screen? If the answer is no, there is a problem. This applies to fields that are visible by default (not fields that are only shown under specific conditions). If you have to search for information, efficiency is lost.

The key is to find the balance. Too few fields can result in a lack of context, while too many fields create noise and friction. "Field Sprawl" is the gradual shift from balance to noise.

How to Prioritise Which Fields are Actually Used

Identifying redundant fields requires a systematic approach. It is rarely sufficient to assess from a list alone. A combination of quantitative data analysis and qualitative feedback provides the best basis for decisions.

Step 1: Data Collection and Analysis

Zendesk Explore is a central tool for gaining insight into how fields are used (or not used).

1. Create a report for each field: For each custom field to be examined, create a simple Explore report that counts the number of tickets where the field has a value.
2. Identify "ghost fields": Sort fields by how often they are filled in. Fields that are empty in 95%+ of all tickets are prime candidates for removal, as they typically create noise without adding value.
3. Look for "single-value" fields: A dropdown field where one value makes up 99% of all selections is a warning sign. It can indicate that the field is redundant, or that its purpose should be reconsidered. It can also point to a default value that should be part of the process rather than a manual choice.
4. Analyse free-text fields: Fields such as "Description of problem" can be relevant, while a field such as "Additional Info" can become a dumping ground for unstructured data. A text analysis can reveal patterns. If the same thing is often written, it can indicate that the field should be converted into a dropdown field with predefined options.

Step 2: Categorising Fields

Once the data has been collected, categorise each field. A simple four-box model can be used:

• Critical for Operations: Fields that are essential for the workflow. Without these, a case cannot be solved, escalated or routed correctly. Examples: "Customer ID", "Order number", "Problem type". These fields should be retained, optimised and placed within easy reach.
• Important for Reporting: Fields that are not necessarily used directly in the solution, but which are crucial for business insight. Examples: "Reason for enquiry", "Solution type", "Affected product". These fields should be retained, and high data quality should be ensured, as well as an understanding of why they should be filled in.
• Useful for Context: Fields that provide extra information in specific situations, but are not critical for most cases. Examples: "Link to internal wiki page", "Specific software version". These fields are good candidates for being made conditional (see the next section) or hidden from the default view.
• Obsolete/Unused: Fields that, according to analysis and feedback, are not used, or that have become redundant after process changes. These fields should be removed.

Step 3: The Hard Decision - Removing Fields

Deleting a field can feel like a major decision. A recommended approach is to follow a "deprecation" process before deletion.

1. Hide the field: The field is first hidden from all agent views and ticket forms, so that it is no longer visible to users.
2. Observe for a period: The field is kept hidden for 2-4 weeks. Feedback from agents is monitored, e.g. "Field X can no longer be found, and it is used for [specific use case]". If no need arises, the field is closer to being deleted.
3. Communicate: Before deletion, a message is sent in a relevant channel (e.g. Slack or Teams) about the planned deletion of unused fields. The fields are listed, and a final opportunity to object is given.
4. Delete: If no objections are raised, the field can be deleted. The data in the field is removed, but once it has been established that the field was not used, the risk is assessed as acceptable.

The process reduces the risk of affecting hidden but important processes, and at the same time creates trust because agents are involved.

Field Dependencies - How to Keep the Logic Simple

Field dependencies (conditional fields) are a powerful tool in Zendesk that can show or hide fields based on the value in another field. Used correctly, this can reduce "Field Sprawl" significantly and guide the agent through a logical process. Used incorrectly, it can create an unmanageable web of logic.

The Power of Simple Logic

An example of simple and effective logic:

• Field 1 (Dropdown): Problem type

  • Value A: "Technical Error"
  • Value B: "Invoice query"
  • Value C: "Other"

• Dependency:

  • If "Problem type" is "Technical Error", show the "Product" field (dropdown) and the "Error message" field (text field).
  • If "Problem type" is "Invoice query", show the "Order number" field (text field).
  • If "Problem type" is "Other", show the "Description" field (text field).

This provides several benefits:

1. Reduced noise: Only relevant fields are shown for the specific enquiry.
2. Guided process: The agent is guided to collect the relevant information.
3. Higher data quality: Dropdowns provide structured data, which is easier to report on.

This is a green flag: A clear dependency with a clear purpose.

The Pitfalls - When the Logic Becomes a Spider's Web

Challenges arise when dependencies are built on top of dependencies.

Example of bad logic:

• If "Problem type" is "Technical Error", show "Product".
• If "Product" is "Software X", show "Version".
• If "Version" is "v2.0", show "Module".
• If "Module" is "Billing", show "Error code".
• ...and so on.

Why is this problematic?

• Unmanageable: The logic is difficult to maintain and troubleshoot. Changes in one place can have unforeseen consequences further down the chain.
• Confusing for the agent: The overview can be lost. A wrong choice early on can require the process to be started over.
• Hidden fields: The ticket form can end up with many fields, most of which are hidden most of the time, creating administrative clutter.

A rule of thumb for dependencies is: A maximum of two levels. One field depends on another, but rarely on a third. If more complex logic is needed, consider whether it can be solved in another way, e.g. with different ticket forms for different purposes or with macros that fill in fields based on choices.

Red flag: A dependency chain of more than two levels, or a ticket form where more than half of the fields are hidden by default.

Cleanup Strategy for Unused Fields

A "big bang" clean-up can be risky. A more controlled and sustainable approach is to establish an ongoing cleanup strategy.

Preparation: Make a Backup and a Plan

Before changes are made, there should be a plan in place.

1. Document the current state: Draw up a list of all custom fields, including field name, field type, purpose (if known) and where the field is used (views, forms, triggers). A simple spreadsheet works well.
2. Communicate the intention: Inform the team and relevant stakeholders that the custom fields are being reviewed and optimised to improve efficiency, and why it matters. This builds support.
3. Set aside time: The task is rarely solved in one afternoon. Dedicated time should be set aside over several weeks.

Execution: Deprecation Before Deletion

"Deprecation" is a safe approach. A roadmap might look like this:

1. Phase 1: Identification (Week 1)

   • Use the Explore method to identify candidates for removal.
   • Hold workshops with agent teams to gather qualitative feedback, e.g.: "Which fields are never used?" and "Which fields are confusing?".
   • Update the spreadsheet with your findings and categorise the fields (Critical, Reporting, Context, Obsolete).

2. Phase 2: Hiding and Observation (Weeks 2-5)

   • Go to "Ticket Fields" in Zendesk Admin.
   • For fields in the "Context" and "Obsolete" categories, clear the "Visible to agents" checkbox.
   • This hides the field from views and forms. Note: If the field is required, it must first be removed from the relevant forms before it can be hidden.
   • Observe and gather feedback. If fields are requested, clarify the reason. The field can be moved to another category, or the exception can be handled in another way.

3. Phase 3: Final Approval and Deletion (Week 6)

   • Review the list again. Fields that have not been requested are ready for deletion.
   • Send a final notification, e.g.: "As previously communicated, the following fields are now being deleted, as they have not been used in the last few weeks: [list]". State a deadline for objections (e.g. 24 hours).
   • Delete the fields permanently.

Automation and Maintenance

Clean-up is not a one-off task. To prevent "Field Sprawl" from returning, a forward-looking process should be established.

• Quarterly review: Schedule a fixed quarterly review of fields using the same method. It typically takes less time when carried out on an ongoing basis.
• Create a "Field Request" process: Make it clear how new fields are requested. A simple process can include a form where the need is justified:
  1. What is the purpose of the field?
  2. Which process does it improve?
  3. Who will use the data (agents, management, etc.)?
  4. Which field type should be used (dropdown, text, etc.)?
  5. Does a field that could be used already exist?

The process supports an assessment of necessity and provides a better basis for approving or rejecting the request.

Common Field Mistakes and How to Avoid Them

The same mistakes are often seen again and again. Below are the most common pitfalls, as well as ways to avoid them.

Mistake 1: Poor Naming

• Symptoms: Field names such as "Info", "Data", "Custom Field 12345", "Dropdown 2", where the purpose is not clear.
• Consequence: Uncertainty about what should be filled in, and the data becomes useless for reporting.
• Solution: Establish a naming convention. A usable model is [Category] - [Specific Purpose]. Examples: [Customer] - Customer number, [Product] - Model, [Internal] - Escalation reason. Consistency is crucial.

Mistake 2: Wrong Field Type

• Symptoms: Using a text field for data that should be structured (e.g. typing "High", "Medium", "Low" in a priority field instead of selecting it).
• Consequence: Low data quality and difficult reporting due to many variations of the same value ("High", "high", "high priority", "High!").
• Solution: Assess the data type before creating the field:
  • Use a Dropdown for a fixed number of choices.
  • Use Multi-select for multiple choices from a fixed list.
  • Use a Checkbox for yes/no questions.
  • Use Text only for unique, unstructured information such as serial numbers or comments.

Mistake 3: Lack of Documentation

• Symptoms: Three different agents give three different explanations of what a field means.
• Consequence: Inconsistent use, incorrect data and confusion.
• Solution: Create a central "Field Dictionary", e.g. in an internal wiki (Confluence, Notion, etc.) or a Google Sheet. For each field, document:
  • Field name
  • Purpose (short and precise)
  • Who is responsible for filling in the field
  • What the values mean (especially for dropdowns)
  • Examples of correct use

Mistake 4: Ignoring Standard Fields

• Symptoms: Creating custom fields such as "Priority" or "Status", even though Zendesk already has standard fields for these.
• Consequence: Duplicated data, confusion about which field is correct, and problems with integrations and automations that expect standard fields.
• Solution: Know the standard fields. Zendesk has built-in logic in fields such as Type, Priority, Status, Group, Assignee. Processes should, as far as possible, be adapted to standard fields before creating custom fields with the same function.

Mistake 5: Making Fields Required Without Reason

• Symptoms: Ticket forms with many required fields, where a large proportion are not relevant to the majority of enquiries.
• Consequence: Agent frustration and "garbage data". When an irrelevant field has to be filled in, values often end up as "N/A" or random entries.
• Solution: Assess strictly which fields really need to be required. Only fields that are critical for a case to exist should be required across the board. For other fields, conditional fields can be used, or the fields can be made optional.

Red Flags vs. Green Flags - Quick Checklist

The checklist below can be used to assess the state of health of a Zendesk instance.

Red Flags: Warning Signs that Require Action

• Over 100 custom fields: A strong sign of "Field Sprawl".
• Complaints about a cluttered and long ticket form: Feedback from agents is central, as the form is used daily.
• No explanation of the purpose of fields: If the purpose is unclear, the field is typically also without value.
• Explore reports with many empty columns: A waste of space and mental energy.
• Complex, nested dependencies: Create a high maintenance risk.
• No process for approving new fields: Fields are created ad hoc without governance.

Green Flags: Signs of a Well-Run Zendesk Instance

• Fewer than 30-40 custom fields with a clear purpose: Quality over quantity.
• Short, clean and intuitive ticket forms: Necessary fields can be found immediately.
• Accessible documentation (e.g. a "Field Dictionary"): Transparency supports consistent use.
• Fast and accurate reporting: Relevant and well-defined data points make reporting more efficient.
• Simple, effective field dependencies: Irrelevant fields are hidden, and the agent is guided.
• A formal process for requesting and approving new fields: A justification of necessity is included.

Controlling custom fields is an ongoing task and a valuable investment for Zendesk administration. It is not just about clean-up, but about creating a foundation for efficiency, clarity and data-driven decision-making. A proactive and systematic approach can transform Zendesk from an unmanageable store of unused data into a sharp and efficient tool that supports both agents and the business.