How to Create Custom Ticket Fields & Forms in Freshdesk

What a ticket field actually is

A ticket field is one input on the ticket form — a dropdown, a text box, a checkbox — that stores a piece of structured data against every ticket. Freshdesk ships with 10 default fields you can reorder and relabel but not delete: Requester, Subject, Type, Source, Status, Priority, Group, Agent, Product, Description, and Company. On top of those you add custom fields of your own.

Per Freshworks' Understand and Customize Ticket Fields documentation, there are eight custom field types:

• Single-line text — a short free-text answer (order number, serial).
• Multi-line text — a longer paragraph answer (steps to reproduce).
• Checkbox — a single yes/no toggle.
• Dropdown — a fixed list of choices, the workhorse for structured data.
• Dependent field — a cascading three-level dropdown (more below).
• Date — a date picker.
• Number — a whole number.
• Decimal — a number with decimal places.

Custom fields are available from the Growth plan onward. The count you can create scales with plan: Growth allows up to 80 single-line text and 80 dropdown fields; Pro and Enterprise raise those to 400 and 250 respectively, with lower ceilings on multi-line, checkbox, date, number, and decimal types. Most teams never come close, but if you're modelling a data-heavy form, confirm the ceilings against your own plan.

Step 1: Open the Ticket Fields builder

Everything lives in one drag-and-drop canvas.

1. Go to Admin → Workflows → Ticket Fields.
2. You'll see your current form in the centre and a field-type palette on the left, labelled "Drag and drop to create fields."
3. Drag a field type from the palette onto the form where you want it to sit.
4. In the panel that opens, set its labels and behaviour (Step 2), then Save.

That's the whole loop — drag, configure, save. The order of fields on the canvas is the order agents and customers see them, so put the high-signal fields near the top.

Step 2: Agent-only vs customer-facing — the settings that matter most

This is the part people get wrong, and it's the difference between a clean customer form and one that leaks internal jargon. Each field carries two names and a set of visibility toggles:

• Label for agents — what your team sees in the ticket view.
• Label for customers — what shows on the customer portal / support form. Leave a field's customer visibility off and it becomes agent-only — perfect for internal data like "Refund approved by" or "Root cause category" that customers should never see or set.
• Required when submitting the ticket — forces a value at creation (use sparingly on customer-facing fields; every required field is a reason someone abandons the form).
• Required when closing the ticket — a softer, agent-side gate: the field can stay empty during the conversation but must be filled before the ticket resolves, which is how you guarantee clean data for reporting.
• Can view and Can edit — control whether the customer sees the field at all and whether they can set its value. A field the customer can view but cannot edit is a display-only badge; a field they can neither view nor edit is fully agent-only.

The clean mental model: customer-facing fields collect what you need to triage (product, issue category), while agent-only fields capture what you need to resolve and report (disposition, root cause). Getting this split right is what keeps your form short for customers and rich for agents. It also feeds the priority and type data we break down in Freshdesk ticket types, priority & source explained.

Step 3: Build a dependent field for cascading choices

When you need customers to narrow down through a hierarchy — say Category → Subcategory → Item — a stack of separate dropdowns is clumsy. A dependent field collapses that into one cascading control: pick a category and the relevant subcategories appear; pick a subcategory and the relevant items appear. Freshdesk supports up to three levels.

To build one:

1. Drag the Dependent field type onto the form.
2. Create a label for each of the two or three levels you want (e.g. Category, Subcategory, Item).
3. Enter your choices, one per line, using indentation to signal hierarchy: no indent for a level-1 category, one tab to make the next line a level-2 subcategory, and two tabs for a level-3 item.
4. Add the choices and Save.

The payoff is a form that feels short to the customer but hands your agents a precise, pre-sorted classification — which is gold for routing and for the automation rules we cover in how to set up automations in Freshdesk.

Step 4: Use dynamic sections to reveal fields only when relevant

A long form scares people off; a dynamic section keeps it short by showing a group of fields only when a particular dropdown option is selected. Choose "Billing" as the issue type and the invoice-number and account-email fields appear; choose "Bug" and a steps-to-reproduce field appears instead. Everything else stays hidden until it's needed.

Per Freshworks' Creating dynamic sections guide, dynamic sections are available from the Pro plan onward. To create one:

1. Go to Admin → Workflows → Ticket Fields.
2. Click the plus icon on a dropdown field (you can use the Type, Status, or Group default fields, or any custom dropdown).
3. Name the section and associate it with the specific dropdown choices that should trigger it.
4. Drag new or existing custom fields into the section, set their properties, and Save field.

You can associate dynamic sections with up to five dropdown fields on a single form (for the default fields), and the fields inside a section behave like normal custom fields — they show up in ticket-view filters and can drive automation rules.

Field types at a glance

The honest limits — and where an AI layer picks up

Freshdesk's field-and-form builder is genuinely capable: it's visual, it covers the field types most support teams need, and dependent fields plus dynamic sections let you keep a form short without dumbing it down. For structured data capture, it does the job well and you shouldn't reach for anything heavier than it.

But notice what it can't do. A field is only as good as the value someone puts in it — and the native builder can't fill fields for you. It can make a dropdown required, but it can't read a customer's message, understand that "my package never showed up" is a Delivery → Lost parcel issue, and set the dependent field accordingly. Required customer-facing fields fight the exact goal of a short form: every mandatory dropdown is friction, and customers routinely pick the wrong option or the first one. Agent-only fields still depend on a human remembering to fill them before close. And the form can't reason about the answer — it can capture "order #4471" but it can't go fetch that order's status from your systems.

This is the seam where an AI agent layer fits, and it's worth being clear-eyed about the build-versus-buy tradeoff before you reach for one. The broader category of AI agents for customer service exists to do the reasoning your form can't. Macha is one such layer: it runs on top of the Freshdesk you already use as a native connector — it does not replace your help desk or its ticket fields. You connect Macha to Freshdesk with your subdomain and API key, and it reads and writes the same tickets your form structures: inferring the right category and priority from the customer's own words and populating the fields you built (so structured data is captured even when the customer skips a dropdown), and looking up order or account status through a custom tool that turns a REST API into something the agent can call. (Macha's connector is for Freshdesk specifically — not Freshchat, Freshservice, or Freshcaller. And credits are consumed per AI action, not per resolution — see the pricing breakdown.)

The clean division of labour: keep Freshdesk's ticket fields as the source of truth for what data a ticket carries, and layer an agent on top for the part the form can't do — actually understanding the message well enough to fill those fields correctly. If you're also standardising the replies that go out on those tickets, the companion piece is Freshdesk canned responses explained.

FAQ

Where do I create custom ticket fields in Freshdesk? Go to Admin → Workflows → Ticket Fields. Drag a field type from the left-hand palette onto the form, configure its labels and visibility in the panel that opens, and save. Custom fields are available from the Growth plan onward.

What field types can I add? Eight custom types: single-line text, multi-line text, checkbox, dropdown, dependent field, date, number, and decimal — alongside the 10 built-in default fields like Type, Priority, Group, and Company.

What's the difference between an agent-only and a customer-facing field? It's controlled by the field's visibility settings. A field with customer Can view / Can edit enabled shows on the support portal for customers to fill; turn those off and it becomes agent-only — visible and editable only inside Freshdesk, ideal for internal data like root cause or disposition.

How do dependent fields and dynamic sections differ? A dependent field is a single cascading control with up to three linked levels (Category → Subcategory → Item). A dynamic section reveals a whole group of separate fields when a specific dropdown option is chosen. Dependent fields are about narrowing one choice; dynamic sections are about showing the right block of fields for the situation. Dynamic sections require the Pro plan or higher.

Can I add AI to Freshdesk ticket fields without replacing Freshdesk? Yes. An AI agent layer like Macha connects to Freshdesk as a native connector and runs on top of your existing help desk and its ticket fields — it doesn't replace them. It helps populate those fields by reading the ticket, inferring category and priority, and writing values back, while Freshdesk stays the system of record for the data itself.

Ready to capture clean ticket data without a longer form? Start a free trial of Macha and connect it to your Freshdesk in minutes.