Ticket Categories

🏷️ Ticket categories

A ticket type says what kind of thing this is — an incident, a service request. A category says what it is about: printing, user onboarding, access requests. This page covers the category list and the two fields that sit beside it.

Shipped as #1540–#1548 in 1.5.0. Asked for by a prospective user by email:

In our current ticketing platform, we can create and add a category to each ticket. For example, for a 'service request' could have a category such as 'user onboarding' or for 'incident' a category such as 'printing issues'.

The developer guide is Ticket categories — Developer Guide.

---

1. 🧭 Three fields, three questions

Everything here lives under Tickets → Settings → Categories.

Field	Asks	When
Category	What was this reported as?	When the ticket is raised
Category at close	What did it turn out to be?	When the ticket finishes
Resolution code	How did it end?	When the ticket finishes

The first two share the same list. Most of the time an analyst simply confirms what is already there — the second field earns its place on the ones where the first guess was wrong.

A worked example. A user raises "my printer keeps going offline."

• Category at open: Hardware → Printer
• The analyst finds the office Wi-Fi access point is dropping
• Category at close: Network → Wi-Fi

At the end of the quarter you can now say "37 tickets were reported as printer problems; 12 of them were actually the network." That is the buy-a-new-access-point conversation, and without the second field the printer number is simply wrong and nothing tells you.

A resolution code is a different question again — not what it was about, but how it ended. Ten are there from the start:

Fixed remotely · Fixed on site · Hardware replaced · Configuration change · Training given · Access granted · No fault found · Duplicate · Withdrawn · Referred to supplier

That is the field that most quickly changes what you do. A fifth of your tickets coming back as Training given is a documentation problem, not an IT one.

---

2. ⬜ All three start switched off

Nothing appears on your ticket screen until you turn it on. Build the list first, then switch on the fields you want.

Each field has its own switch, and each can be set differently per company on a multi-company install. They are independent on purpose — category off, category at close on is a real service desk. Don't make the person raising the ticket guess; let the analyst classify once they actually know.

Turning a switch off never deletes anything. A ticket that already has a category keeps it, and it comes back untouched when you switch the field on again.

---

3. 🌳 Building the list

Add a category, then add sub-categories underneath it if you want them — up to three levels, and no level is compulsory. A flat list of ten is a perfectly good answer.

Hardware
  └ Printer
      └ Toner
Access requests
  └ New starter
Network

Tying a category to a ticket type. A category can be tied to one type, so User onboarding is only ever offered on a service request. Leave the type as Any type and it appears on everything.

⚠️ The tie belongs to the top-level category, and its sub-categories follow it. A sub-category cannot claim a different type from its parent — otherwise "Hardware → Printer" could be an incident while "Hardware" was a service request, and neither answer would be wrong.

If you change a ticket's type, a category that belonged to the old type is cleared, and the screen says so. A category not tied to any type survives the change. The clear is recorded in the ticket's history with the full category path, so it is never a silent loss.

---

4. 🙋 What customers see

Each category carries a Customers can pick this tick. Requesters get a short list in plain English on the portal's What is this about? field while analysts see the whole tree.

The picker is optional and only appears if you have switched the category field on and have at least one portal-visible category. Not sure is a perfectly good answer — the analyst confirms the real category at the end, which is exactly what Category at close is for.

Categories tied to a ticket type are never offered on the portal, because the portal form has no ticket type field to give them any context.

---

5. 🗄️ Retiring, not deleting

Switch a category off to retire it. It stays on the tickets that already carry it and stops being offered on new ones — which is almost always what you want.

Deleting is refused while anything still points at it, and the message says which:

• "This category has 2 sub-categories underneath it. Move or delete those first."
• "Tickets still use this category (14 as their category, 3 as their category at close). Switch it off instead."

That second one checks both columns, because a category only ever picked at close would otherwise sail past a check that looked at the opening one alone.

---

6. 📊 One category per ticket, and why

A ticket carries exactly one category. That is deliberate, and it is about reporting.

Every count in FreeITSM is one ticket, one slice. Let a ticket hold three categories and it gets counted three times: your pie chart totals more than 100%, and every "X% of tickets were printing" on the page becomes wrong. It isn't a chart bug you can patch — the question "what share of tickets were printing?" stops having an answer.

If you want cross-cutting labels, that is what tags are for. The hard rule: tags filter and search; tags never appear in a count-by chart.

On the dashboard, all three fields can be charted. The two category charts roll up to the top level — a leaf-level chart of a three-deep tree is a hundred slices nobody can read — and tickets with nothing set are counted as Not categorised rather than quietly dropped.

---

7. 🧩 Where to start

If you are not sure, don't build a taxonomy on day one. FreeITSM deliberately ships no categories at all, because a category tree is the one thing every organisation has to own and a pre-seeded one is just somebody else's wrong answer that has to be deleted first.

A reasonable order:

1. Turn on Resolution code alone and leave it a month. It is already populated and it will tell you something.
2. Add five or six top-level categories from what you actually saw.
3. Add sub-categories only where one category is drowning everything else.
4. Turn on Category at close once people are used to the list.

---

See also

• Ticket categories — Developer Guide
• Tickets
• One board across every company — how categories behave when a board holds several companies at once