A GLPI installation with 200 ticket categories and no structure is worse than one with 15 well-designed ones. Categories and templates are the intake layer — they determine what information gets captured, how tickets get routed, and whether reporting produces anything useful.
Category design
GLPI supports hierarchical categories. The temptation is to model every possible issue type — Hardware > Laptop > Screen > Flickering. The result is a tree so deep that users can’t find their category, agents miscategorize half the tickets, and reports become meaningless because data is spread across 200 buckets.
A practical approach:
- Two levels maximum — a parent category and one child level. "Hardware > Laptop" is enough. The agent will note the specific issue in the description.
- 10-20 leaf categories total — if you have more, some are too specific. Merge them.
- Name categories by what the user experiences — "Can’t access application" instead of "Authentication failure on SSO IdP." The user picks categories; the agent diagnoses causes.
- One catch-all category — "Other / General" for anything that doesn’t fit. Monitor its volume — if it’s above 15%, your categories aren’t covering real demand.
Ticket templates
Templates in GLPI pre-fill ticket fields based on the selected category. When a user selects "New employee onboarding," the template can:
- Set the ticket type to "Request" (not "Incident")
- Pre-fill the description with a checklist: laptop needed? Software list? AD groups? Building access?
- Set the assigned group to "HR & IT Onboarding"
- Attach the SLA for requests (5 business days instead of 4 hours)
The key is that templates reduce the user’s cognitive load. Instead of filling a blank form, they answer specific questions. Instead of choosing a priority (they always pick "urgent"), the template sets it automatically.
Mandatory fields
GLPI lets you make fields mandatory per category. For a hardware issue, require the asset tag. For a software request, require the application name. For an access request, require the user to specify which system.
The trick is requiring only what’s needed for routing and triage — not everything an agent might eventually want. If the form has 12 mandatory fields, users will fill half of them with "n/a" and you’ve gained nothing.
Self-service vs. agent intake
Categories and templates serve two audiences:
- End users via the self-service portal — they see simplified categories and guided forms. Hide internal categories they’d never use (like "Infrastructure > Firewall rule change").
- Agents via the technician interface — they see the full category tree and can override template defaults when needed.
GLPI controls this visibility through profiles. The "Self-service" profile shows one set of categories; the "Technician" profile shows all of them. Design the self-service view first — it’s your most important intake channel.
Maintaining categories over time
Review your category tree quarterly. Merge categories with fewer than 5 tickets per month — they’re adding complexity without value. Split categories that are too broad (the catch-all is growing). Rename categories that users consistently misinterpret. A clean category tree makes every downstream process — routing, SLA, reporting — work better.