Freshdesk Ticket Fields & Forms Explained (Custom & Dynamic)

What ticket fields are in Freshdesk

A ticket field is a single property attached to every ticket — Priority, Status, or a custom "Order number" box you added yourself. Collectively, the fields define two things at once: the agent form your team fills in inside the workspace, and the customer form on your support portal (the "Submit a ticket" page). They're two views of the same underlying set of fields, which is why a change in one place ripples into the other.

Freshdesk ships a batch of default fields that you can rename and reorder but not delete: Requester, Subject, Type, Source, Status, Priority, Group, Agent, and the Description body. A few carry special behavior. Source is system-set and read-only — Freshdesk stamps it with the channel the ticket came in on (email, portal, chat, phone, API) so your rules and reports can key off it. Status and Priority drive SLA timers and escalations. Type is a dropdown you'll almost certainly customize — the out-of-the-box choices are Question, Incident, Problem, Feature Request, and Refund, and it's the field most teams lean on for routing.

On top of the defaults, you add custom fields: the account IDs, order numbers, product lines, subscription tiers, and reason codes that make a ticket meaningful for your business. Those custom fields are where ticketing stops being a generic inbox and starts reflecting how your team actually works.

Field types you can use

You build the form in Admin → Workflows → Ticket Fields, dragging field types from a palette onto the form and configuring each one. Per Freshdesk's Customizing Ticket Fields documentation, the types you can add are:

• Single-line text — short free text like an order number or account ID.
• Multi-line (paragraph) text — longer descriptions or notes.
• Dropdown — a fixed list of choices (product, region, reason). The workhorse for routing and reporting because the values are clean and consistent.
• Checkbox — a single yes/no toggle, e.g. "VIP customer" or "Consent to contact."
• Number and Decimal — quantities, amounts, counts.
• Date — a calendar picker, e.g. purchase date or requested-by date.
• Dependent field — a three-level cascading dropdown where each choice narrows the next (the classic Country → State → City). This is capped at three levels.

The golden rule: prefer dropdowns over free text wherever you'll want to filter, route, or report. "Billing," "billing," and "Bill" are three different strings to an automation but one intent to a human — a dropdown removes that ambiguity before it ever reaches a rule.

Required, visible, editable: the toggles that matter

Each field carries a set of independent switches, and they're the part new admins most often get wrong. For every field you can decide whether it's:

• Displayed to customers — shown on the portal form, or agent-only. Internal reason codes usually stay agent-only.
• Required when submitting the form — the customer can't submit without filling it in. Use sparingly; every required field is friction that pushes people toward email instead.
• Editable by customers — whether the requester can change the value after submitting.
• Required to resolve/close the ticket — an agent-side gate that forces the field to be filled before the ticket can be closed. This is how you guarantee a "Root cause" or "Resolution code" is always captured for reporting, without pestering the customer for it up front.

The distinction between required for customers and required for agents is the one to internalize: you keep the customer form short and friendly, while still guaranteeing your team captures the structured data your analytics need before closing.

Dynamic (dependent) sections

A flat form that asks everyone everything is a bad form. Dynamic sections — also called field sections — fix that by revealing extra fields only when they're relevant. You attach a section to specific values of a dropdown (most often Type): pick "Refund" and a refund-amount and order-date section appears; pick "Bug" and a severity and steps-to-reproduce section shows instead. The customer only ever sees the questions that apply to their situation, and you still collect rich, structured data behind the scenes.

This is distinct from the dependent field above (the three-level cascading dropdown). Sections show or hide whole groups of fields based on a choice; dependent fields narrow one choice into the next. Availability of multiple forms and some section behavior varies by Freshdesk plan, with the richer configurations on the higher tiers — confirm the exact labels and limits in your own account, since Freshworks reshuffles this area periodically. For the broader picture of what these fields feed into, see our Freshdesk features overview.

Where native fields stop — and an AI layer begins

Ticket fields are excellent at storing structure and mediocre at creating it. Freshdesk can't force a customer to describe their problem well; it can only give them boxes and hope. In practice, a huge share of tickets still arrive with the dropdowns skipped, the wrong Type selected, or the whole story crammed into the Description while the "Order number" field sits empty. Someone — usually an agent — then reads the message and back-fills the fields by hand. That's the tax native fields quietly impose.

This is where Macha comes in. Macha is an AI agent layer that runs on top of Freshdesk as a native connector — not a replacement for it. (Macha connects to Freshdesk specifically; it does not connect to Freshchat, Freshservice, or Freshcaller.) Because it reads and writes real tickets through the Freshdesk API, a Macha agent can read the customer's message the moment it lands, infer the Type, set the Priority, and populate custom fields like order number or product line from the text itself — then reply, or hand a fully-structured ticket to an agent. The form still exists; the agent just stops being the one who fills it in.

The pieces that make this trustworthy rather than a black box: Custom Tools let an agent turn any REST API into a callable action, so it can look up an order in your commerce system and write the real value into a Freshdesk field instead of guessing. Sources ground its answers in your help center so replies match documented policy. And Studies batch-grade the agent against real historical tickets before it ever touches a live queue — you see how it would have classified and answered hundreds of past tickets, and only ship when the numbers are good. If you're weighing whether to assemble this yourself, our guide on building an AI agent from scratch versus using a platform walks the trade-offs, and AI agents for customer service covers the category. For the Freshdesk-specific setup, see how to automate Freshdesk with AI.

FAQ

What's the difference between default and custom fields in Freshdesk? Default fields (Requester, Subject, Type, Source, Status, Priority, Group, Agent, Description) ship with every Freshdesk account and can be renamed and reordered but not deleted. Custom fields are ones you add yourself in Admin → Workflows → Ticket Fields — order numbers, product lines, reason codes — to capture data specific to your business.

What is a dependent field versus a dynamic section? A dependent field is a single three-level cascading dropdown where each choice narrows the next (Country → State → City), capped at three levels. A dynamic section reveals a whole group of extra fields based on a dropdown value — for example, showing refund fields only when Type is set to "Refund." One narrows a choice; the other shows or hides groups of fields.

Can I make a field required for agents but not for customers? Yes. Freshdesk gives each field independent toggles. You can leave a field off the customer portal form (or optional there) while marking it "required to resolve/close the ticket" on the agent side — so you keep the customer form short but still guarantee agents capture the data before closing.

Can Macha fill in Freshdesk ticket fields automatically? Yes. Macha runs as a native AI agent layer on top of Freshdesk (it connects to Freshdesk, not Freshchat/Freshservice/Freshcaller). It reads the incoming message, infers Type and Priority, and can populate custom fields — using Custom Tools to pull real values from your own systems — then reply or hand a structured ticket to an agent. You can grade it against real past tickets with Studies before going live; see pricing for plan details.