Priority matrix — impact × urgency

Priority matrix

When an agent (or the portal) sets a ticket’s impact and urgency, the priority matrix decides what the ticket’s priority becomes. This is how P1/P2/P3/P4 (or Urgent/High/Medium/Low) get assigned automatically without an agent having to think about it.

The standard ITIL grid

Out of the box, every workspace gets a Standard ITIL matrix — a 4×4 grid where:

• Impact rows: Low / Medium / High / Critical
• Urgency columns: Low / Medium / High / Critical
• Priority cells: P1 / P2 / P3 / P4 (red → green)

The cell mapping follows the standard rule: high impact × high urgency = P1; low × low = P4; everything else slopes diagonally between.

Editing the matrix

Open Helpdesk → Priority matrix in the admin shell, then click any matrix to edit it. Three things you can change:

1. Levels — rename, recolour, reorder, or add impact/urgency/priority levels. A 5-tier matrix (P1–P5) is supported.
2. Cells — click any cell in the grid to change which priority that combination maps to.
3. SLA hours — each priority level carries a default SLA-hours number that the SLA editor’s “Apply matrix defaults” button uses to pre-fill response & resolution times.

Per-department matrices

Trusts often want different cell mappings per team. Estates’ “high × high” might warrant P1 because of safety-of-fabric concerns; HR’s might be P2.

To set this up, click New matrix and pick a department in the matrix’s settings. The new matrix becomes that department’s matrix; everyone else keeps using the workspace default.

When a ticket is created or edited, the engine looks for a matrix bound to the ticket’s department first, and falls back to the workspace default if there isn’t one.

What if I add a 5th level?

The Tickets data model carries one of four priority enum values internally — Low, Medium, High, Urgent. So if your matrix is 5-level (P1–P5), the system clamps anything above P4 back to Urgent when it stores the ticket. The custom labels still appear in the SLA editor and in the matrix UI; the underlying priority just rounds to the nearest of four.

This is a deliberate trade-off — it keeps Tickets queryable by priority without requiring per-workspace migrations.