Every GLPI ticket has three numeric fields that look similar enough to confuse new admins: Urgency, Impact, and Priority. They mean different things. Urgency is how fast it needs to be addressed — set by the requester. Impact is how much business it disrupts — set by the agent after triage. Priority is the result of multiplying them through a configurable 5×5 matrix. Most installations run the default matrix without ever opening it, and then complain that priorities don't match how the team actually triages.
Where the matrix lives
Open Setup > General > Assistance. Scroll to the section labeled Matrix of calculated priority based on impact and urgency. It's a 5×5 grid. Rows are Impact (1 = Very low → 5 = Very high). Columns are Urgency (same scale). Each cell contains a priority value from 1 (Very low) to 5 (Very high). The cell at (Impact=5, Urgency=5) defaults to Priority 5 (Major). The cell at (Impact=1, Urgency=1) defaults to Priority 1.
You can edit any cell. The matrix is global — there's only one for the entire GLPI install — and changes take effect on new tickets immediately. Existing open tickets retain their previously-calculated priority unless explicitly recalculated.
Why the default matrix is rarely right
The default matrix is symmetric: urgency and impact contribute equally to priority. That sounds reasonable until you watch real triage. In most organizations, impact dominates. A whole-department outage with low individual urgency (the team is in a meeting, nobody is calling yet) still needs to be P1 because the moment that meeting ends, fifty tickets land. Conversely, "urgent" complaints from one user about a slow laptop, no matter how loudly stated, are P3 at best.
The fix is to weight the matrix toward impact: row 5 (high impact) maps to P4 or P5 across most urgency columns. Row 1 (low impact) maps to P1 or P2 even when urgency is high. The result: priority follows what actually disrupts work, not what the requester insists on.
Calibrate from real tickets
Look at your last 100 closed tickets where priority was changed by an agent after submission. The pattern of those changes is the matrix you actually use. Take the 5 most common urgency/impact combinations and check what priority your team set them to — that's the desired output. Adjust those cells.
Example pattern often found in real installs: an "Application down for whole department" (Impact=4, Urgency=3) consistently gets bumped to P4 by agents, even though the default matrix puts that combination at P3. Update the cell. After three months of agents not having to manually bump those tickets, you'll find the queue auto-organizes correctly.
Educate requesters on urgency, train agents on impact
Urgency belongs to the requester. Don't try to second-guess it from the matrix — that's the agent's job during triage. Instead, give requesters a clear definition for each value:
- Very low — can wait several days, has a workaround
- Low — should be resolved this week
- Medium — slowing my work today
- High — blocking me from working at all
- Very high — emergency affecting multiple people
Impact is set by the agent after asking three questions: how many people are affected (just the requester / team / department / whole org), is there a workaround, and is revenue or compliance at risk. The agent reads, asks, updates impact. The matrix then produces a priority. The agent doesn't override the priority — they override the impact value and let the matrix do its job.
Map priorities to SLAs, not the other way around
Once the matrix produces the right priorities, link priorities to SLAs via a business rule (Administration > Rules > Rules for assigning a ticket created through the helpdesk): if priority equals 5, assign SLA P1; if priority equals 4, assign SLA P2; etc. This is the cleaner separation than skipping priority and assigning SLAs directly from urgency/impact — because priority is what's visible on every ticket list, every report, every notification. Get the matrix right and the rest of the system organizes around it.