Freshdesk Ticket Types, Priority & Source Explained

The four categorisation fields, at a glance

Freshdesk ships with a standard set of default ticket fields — Requester, Subject, Type, Source, Status, Priority, Group, Agent, Product, Description, and Company — that you manage under Admin → Workflows → Ticket Fields, per Freshworks' Understand and Customize Ticket Fields documentation. Four of them do the categorisation work:

The rest of this piece takes them one at a time.

Type: the field you define yourself

Type is the one categorisation field Freshdesk leaves entirely up to you. There are no default Type values out of the box — you create the list that fits your business. A SaaS company might use Billing, Bug, Feature Request, and Question; a retailer might use Order Issue, Return, Shipping, and Product Question. The docs give Billing, Error, and Feature Request as illustrative examples, but nothing is imposed on you.

Type is deliberately lightweight. It answers "what kind of request is this?" in one word, which makes it the natural pivot for reporting ("how many bugs did we get last month?") and for routing ("send all Billing tickets to the finance group"). Because you own the list, keep it short and unambiguous — five to eight types is usually plenty. Overlapping or vague types ("Other", "General") are where categorisation quietly falls apart, because agents stop trusting the field and leave it blank.

You can also let customers pick a Type when they submit a ticket by enabling the field's Display to customer option under Admin → Workflows → Ticket Fields, as covered in Freshworks' guide on how customers can change the priority and type of a ticket. That can help intake, but customer-selected Type is a hint, not a source of truth — people mislabel their own tickets constantly, which is a limitation we'll return to.

Priority: four fixed levels, wired to SLAs

Priority has exactly four values — Low, Medium, High, and Urgent — and unlike Type, you cannot change them. Freshworks hard-codes these because Priority is tied directly to SLA Policies: your SLA targets ("respond to Urgent within 1 hour, resolve High within 8 hours") reference these levels by name, so letting admins rename or add to them would break the SLA engine. If you genuinely need a fifth tier, the documented workaround is to build a custom dropdown field and run your automations against that instead — but you lose the native SLA linkage when you do.

Priority can be set three ways: manually by an agent, automatically by an automation rule, or — if you allow it — by the customer at submission. In practice most teams default new tickets to Low or Medium and let automations or agents escalate from there, because a customer's sense of "Urgent" rarely matches yours.

The properties panel above shows Type, Status, and Priority sitting together on a single ticket — the everyday view an agent works from. Note that Source isn't a dropdown in this panel; it's conveyed by the "reported via email" line at the top of the ticket, which is exactly the behaviour we'll unpack next.

Status: the lifecycle field

Status tracks where a ticket sits in its journey, and it comes with four mandatory values — Open, Pending, Resolved, and Closed — that cannot be deleted. Open means it's live and needs attention; Pending means you're waiting on the customer or a third party; Resolved means you believe it's done; Closed means it's finalised. On the Growth plan and above you can add custom statuses (for example, "Waiting on Engineering") to model your own workflow, but the four defaults always remain.

Status is the field automations lean on most heavily for housekeeping — reopening Resolved tickets when a customer replies, auto-closing Resolved tickets after a set number of days, and so on. It's less a "categorisation" than a "state machine," but it lives in the same panel and gets set by the same mix of agents and rules.

Source: set automatically by the channel

Source is the field you almost never touch, because Freshdesk fills it in for you. When a ticket is created, Freshdesk stamps it with the channel it arrived on — email, the support portal, phone, chat, a feedback widget, and so on. Per the ticket fields documentation, Source has 13 default choices that cannot be edited or deleted (though they can be rearranged), and it is automatically populated based on the channel used to create the ticket. On Growth and above you can add your own custom sources to reflect additional ways customers reach you.

This is the important nuance the ticket screen can hide: Source usually isn't a dropdown you pick from in the properties panel the way Type or Priority is. On an email ticket it shows up as a "reported via email" line near the top of the conversation — the ticket knows it came in by email without anyone selecting anything. Because Source is set at creation and reflects a real, trustworthy signal (the channel), it's one of the most reliable fields to build automations on: "route all phone-sourced tickets to the callback group" will fire correctly every time, because the channel is a fact, not a guess.

How automations key off these four fields

This is where categorisation pays off. Freshdesk's automation rules that run on ticket creation and its rules that run on ticket updates both read and write these fields. Every rule is an if-this-then-that statement, and Type, Priority, Status, and Source are among the most common conditions and actions. A few concrete examples:

1. Condition on Source, action on Group. If Source is Phone → set Group to Callbacks. Reliable because Source is machine-set.
2. Condition on subject keywords, action on Type. If subject contains "invoice" or "refund" → set Type to Billing. This backfills the field customers leave blank.
3. Condition on Type, action on Priority. If Type is Bug AND description contains "down" or "outage" → set Priority to Urgent.
4. Condition on Status, action on Status. If Status is Resolved AND customer replies → set Status to Open (a classic reopen rule).

For the full picture of how Freshdesk's rule engine is structured — the Dispatch'r, Observer, and Supervisor rule types and when each one fires — see our companion guide, Freshdesk automations explained. The short version: these four fields are the levers, and automations are what pull them.

The honest limits — where categorisation breaks down

Freshdesk's categorisation is clean, fast, and dependable for what it is. But it has a hard ceiling, and it's worth naming honestly. Every automation that touches these fields is deterministic keyword-and-field matching. A rule can see that a subject contains "refund," but it cannot understand that "I was charged twice and want my money back" means a billing refund when the word "refund" never appears. Type, in particular, is only as good as whoever set it — and customers mislabel their own tickets constantly, while busy agents skip the field entirely. That leaves a long tail of tickets that are either uncategorised or wrongly categorised, and no keyword rule can reliably fix them because the signal it needs is meaning, not a matching string.

This is exactly the seam where an AI layer helps — and it's worth being clear-eyed about the build-versus-buy tradeoff, which we cover in building an AI agent from scratch vs. using a platform. The broader category of AI agents for customer service exists precisely to handle the reasoning-heavy work that rules can't. Macha is one such layer: it runs on top of the Freshdesk you already use as a native connector — it doesn't replace your help desk, it extends it. You connect Macha to Freshdesk with your subdomain and API key, and it reads the same tickets your rules touch, then acts on their meaning: classifying a ticket by intent rather than keyword, setting the right Type and Priority, drafting a first reply grounded in your help center, or looking up an order's status through a custom tool that turns any REST API into something the agent can call. (Macha's connector is for Freshdesk specifically — not Freshchat, Freshservice, or Freshcaller. And Macha's credits are billed per AI action, not per resolution.)

The sensible division of labour: keep Freshdesk's native fields and rules for what they're great at — Source-based routing, SLA timers tied to Priority, and Status housekeeping — and layer an agent on top for the judgment calls, where reading the ticket beats matching a word in it.

FAQ

What are the default ticket types in Freshdesk? There are none — Freshdesk ships the Type field empty and lets you define your own list under Admin → Workflows → Ticket Fields. Common choices are Billing, Bug, Feature Request, and Question, but you own the list and can add or remove types to fit your business.

Can I change Freshdesk's priority levels? No. Priority has four hard-coded values — Low, Medium, High, and Urgent — because it's tied directly to SLA Policies. If you need more tiers, the documented workaround is to create a custom dropdown field and run automations against that, though you lose the native SLA linkage.

How is the Source field set on a Freshdesk ticket? Automatically. Freshdesk stamps each ticket with the channel it arrived on (email, portal, phone, chat, and so on) at creation time. Source has 13 default choices that can't be edited or deleted, and you can add custom sources on the Growth plan or above.

Can customers set the type and priority of their own tickets? Yes, if you enable the "Display to customer" option for those fields under Admin → Workflows → Ticket Fields. Bear in mind customer-selected values are hints, not ground truth — people frequently mislabel their own tickets, so many teams correct Type and Priority with automations or agents after intake.

Can I add AI classification 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. It sets Type, Priority, and status based on what the customer actually meant rather than keyword matches, grounded in your knowledge base. See Macha's pricing and the Freshdesk connector for details, or start a free trial.