Zendesk Custom Field Plan template.

What's inside — the exact file

This is the complete template, not a sample. The rows are worked examples — replace them with your data (and delete them before any platform import).

What this template is for

This worksheet is where a Zendesk field architecture gets decided — before anyone opens the admin center. Every custom field on tickets, users, and organizations costs agent attention and admin upkeep, so each one should earn its place: what type is it, who sees it, what consumes it (triggers, views, SLAs, Explore reports), and who owns keeping its options current.

Use it at implementation, before a re-platform, or as the worksheet for a spring cleaning of an instance that has accumulated fields nobody remembers creating. One row per field; if you can’t fill the used_by column, that row is a candidate for deletion, not creation.

How to use it, step by step

1. Inventory what exists. Export your current fields from the admin center (or list them manually) into the sheet, one row each, before designing anything new.
2. Fill used_by for every row. A field that no trigger, view, SLA policy, macro, or report consumes is agent busywork. Mark the consumers explicitly — this column is the whole point of the sheet.
3. Choose types deliberately. Drop-downs beat free text for anything you will route or report on; free text beats drop-downs for anything with unbounded values. Checkbox fields power triggers cleanly.
4. Set visibility per field. Decide agent-visible versus end-user-visible per row. Fields on the request form are a tax on every customer — keep that set minimal and required only when truly required.
5. Assign owners. Every drop-down list drifts out of date. The owner column names who updates options when products, tiers, or teams change.
6. Build from the sheet. Create fields in Zendesk only after the sheet is signed off, then keep the sheet as living documentation of the instance.

What each column means

Common mistakes to avoid

• Creating fields without a named consumer — the used_by column is empty and the field becomes permanent clutter.
• Free-text fields for values you route on. “Billing”, “billing”, and “Billing q” are three different strings to a trigger.
• Making fields required on submit that agents can’t know yet — they will fill them with garbage to move on.
• Exposing internal fields on the end-user form, leaking team structure and slowing every submission.
• No owner for drop-down options, so lists drift out of date and agents invent workarounds.

Questions, answered

How many custom ticket fields is too many?

There is no hard limit that matters — the practical ceiling is agent attention. Our rule from implementations: if the agent must touch more than 4–5 fields per ticket, completion quality collapses. Design for the minimum set with named consumers.

Should a value live on the ticket, the user, or the organization?

Put it where it is true. Customer tier is true of the organization; order number is true of the ticket. Values copied onto tickets that are really org-level facts go stale the moment the org changes.

Can fields be renamed or retyped later?

Renaming is safe; changing a field’s type is not — you generally create a new field and migrate values, which breaks historical reporting continuity. That is exactly why this sheet exists before the build.

This is a Market Disrupt worksheet, not a vendor file. Import-format templates follow each platform's documented layout as of July 2026 — platforms evolve, so validate against current documentation before a large import.