GLPI treats every ticket as either an incident or a request. Most teams ignore this distinction and file everything as an incident. That single oversight corrupts your SLA metrics, muddies your reporting, and makes it impossible to measure what actually matters.
Incidents and requests are not the same thing
An incident means something is broken. A printer stopped working, email is down, a user cannot log in. The goal is to restore normal service as fast as possible.
A request means someone needs something. A new laptop, access to a shared drive, a software installation. The goal is to fulfill the request within an agreed timeframe.
These two ticket types have different urgency profiles, different SLA targets, and different workflows. Mixing them into a single bucket makes your average resolution time meaningless. If your report says "average resolution: 4 hours," is that because incidents take 1 hour and requests take 7? Or because everything takes 4? You cannot tell.
Configuring GLPI to separate them properly
Ticket type field
Every GLPI ticket has a Type field with two values: Incident and Request. Make this field mandatory. Do not let agents or users skip it. In Setup > General > Assistance, you can set the default type, but defaulting to one or the other just encourages people to leave it unchanged. Better to force an explicit choice.
Category mapping
GLPI ticket categories can be restricted to a specific type. Under Setup > Dropdowns > Ticket categories, each category has an "Available for" setting: Incident, Request, or both. Use this. "Email not working" should only appear under Incident. "Request new software" should only appear under Request. This guides users toward the correct type before they even think about it.
Separate SLA rules
In Setup > SLAs, create distinct SLA sets for each type. Incidents might have a 1-hour response / 4-hour resolution target for high priority. Requests might have a 4-hour response / 2-business-day fulfillment target. GLPI lets you assign SLAs automatically using business rules based on ticket type, category, and priority. Set these up so the right SLA attaches without agent intervention.
Separate views for agents
Create saved searches for each type. Agents working the incident queue need to see incidents sorted by priority and age. Agents handling requests need a different view focused on fulfillment deadlines. In GLPI, saved searches can be made public, so set up team-wide views that enforce this separation.
The self-service portal problem
End users do not care about ITIL terminology. They will not instinctively know whether their issue is an incident or a request. The fix is structural, not educational.
In the GLPI self-service portal, configure the category tree so that users pick from a list of specific issues ("I can’t print," "I need a new monitor") rather than choosing a ticket type directly. Each category is already mapped to the correct type behind the scenes. The user describes their problem; GLPI classifies it.
What proper separation tells you
Once incidents and requests are tracked separately, your reports start telling real stories. A spike in incidents points to infrastructure instability. A spike in requests might mean onboarding season or a new project spinning up. The ratio between the two over time shows whether your environment is getting more stable (fewer incidents, steady requests) or degrading (incidents climbing while requests stay flat).
None of this analysis is possible when everything lands in the same pile. The configuration takes an afternoon. The reporting clarity lasts as long as the system runs.