GLPI doesn't have one object for "work" — it has four. Ticket, Problem, Change, Task. Each one fits a different purpose, and confusing them turns the helpdesk into chaos where the technician doesn't know what to deal with first and what's a sub-step of what. This article is about when to use each, how they relate, and how to avoid the "everything is a ticket" anti-pattern.
Ticket: incident and request
The Ticket is the only object an end user fills in. In GLPI a Ticket splits into two sub-types via the Type field:
- Incident — something is broken. "Outlook can't open emails.", "Printer reports an error.", "ERP crashes on login."
- Request — a request for something. "I need a new laptop.", "I want SAP access.", "Password reset."
From the user's view the difference is marginal — both are submitted via the self-service portal and tracked the same way. From a reporting view the difference is critical: incidents are measured by SLA TTR (time to resolve, because something is broken and needs fixing), requests by SLA TTO (when do we start, because something has to be procured or changed). MTTR makes sense for an incident, not for "new laptop in 3 days".
Problem: root cause
A Problem is invisible to the user. The IT team creates it when incidents have been resolved but the technician knows the cause runs deeper and will recur. Example:
- Monday: incident #1234 "Outlook not working" — technician restarts, fixes it.
- Wednesday: incident #1267 "Outlook not working" — different person, different PC.
- Friday: incident #1289 "Outlook not working" — third person.
After the third incident the technician opens a Problem: "Sporadic Outlook failures in M365 environment". The Problem has its own workflow:
- Investigation — collecting logs, reproducing, analysing.
- Root cause — recording the cause (e.g. "M365 update conflicts with antivirus XYZ version 4.2").
- Workaround — temporary fix (disabling a specific AV policy for Outlook).
- Solution — permanent fix (upgrading antivirus to 4.3, or a config change).
Problems make it possible to measure recurring issues and give them strategic attention — something an incident-only model never delivers.
Change: a planned change with approval
A Change is a planned infrastructure change — upgrade, deployment, configuration tweak — that may affect production. Workflow:
- Change proposal — description, reason, impact, plan.
- CAB review — the Change Advisory Board reviews and approves (via GLPI Validations).
- Implementation — execution in the agreed window.
- Post-implementation review — verifying the change is working and didn't introduce regressions.
A Change is the right object for things like: upgrading GLPI from 10.0 to 11.0, deploying a new load balancer, migrating a DNS provider. Not for "give me access to Confluence" — that's a Request.
Task: a sub-task within a ticket
A Task in GLPI isn't a standalone object — it's a sub-task within a ticket, problem, change, or project. On the detail view of a ticket, the Tasks → Add tab adds a task with its own description, assignee, planned time and duration. It's used to break a ticket into concrete steps:
- Ticket: "Onboarding new colleague Karol Novák"
- Task 1: "Create M365 account" (technician A, 30 min)
- Task 2: "Prepare laptop" (technician B, 2 hours)
- Task 3: "Configure VPN" (technician A, 15 min)
- Task 4: "Set up CRM access" (technician C, 30 min)
A Task doesn't generate a user-visible reply on the ticket — it's an internal tool for splitting work. For something the user should see, use a Followup.
Decision matrix
Which object to create for a new request:
Something is broken, reported by a user
→ Ticket type Incident
User wants to receive / do something
→ Ticket type Request
Recurring problem that needs analysis
→ Problem (link related incidents to it)
Planned change with risk of production impact
→ Change (with CAB validations)
Sub-step within an existing ticket/change
→ Task (in the object's Tasks tab)
Long-running initiative with phases and deliverables
→ Project (with tasks and sub-projects)Anti-pattern: "everything is a ticket"
The most common mistake when rolling out GLPI is to use only Tickets. Short-term gain: simplicity. Long-term loss:
- No problem management — recurring issues are never identified, just handled ad hoc forever.
- No change control — risky deployments go in without approval and after a failure nobody can trace who approved what.
- Tickets become epic threads — onboarding "lives" in a single ticket with 40 followups, instead of being split into 5 tasks with owners.
The four object types aren't unnecessary complexity — they're a language for different kinds of work. When the team uses them properly, GLPI stops being "better email" and becomes a real ITSM tool.