Configuring the GLPI priority matrix

How the GLPI priority matrix sets priority and when to change it

When staff pick ticket priorities by feel, the same outage gets a different level depending on who logs it, and escalations and SLA clocks stop meaning anything. The GLPI priority matrix fixes this by combining urgency and impact into a single priority, so the matrix is where your service desk defines that logic once instead of leaving it to each agent. Teams usually change the default matrix for two reasons: to match the way their service model weighs customer effect against business effect, and to hide priority levels they never use so the forms stay short. The exact options, labels and matrix layout depend on the GLPI version you run, so confirm them against the documentation for your release before you draft a target matrix.

Start by writing the matrix on paper before touching the interface. For each combination of urgency and impact, record the priority the service desk expects, then check whether any combination should be impossible or should carry a fixed level for a specific request type. Involve the people who will be paged at night and the people who report to the business, because they will disagree about which cells are too high or too low. Also decide which levels you will disable. Disabling a level hides it from new items but does not rewrite existing records, so review open tickets, problems and changes that already carry the level before you remove it from the choices agents see.

Where urgency, impact and priority apply across GLPI objects

GLPI computes priority from urgency and impact, and the same logic appears on tickets, problems and changes. The cards below separate what a requester or technician enters from what GLPI calculates, so you can confirm how the matrix is applied before you change anything.

Tickets: urgency and impact inputs

On a ticket, the requester or technician sets urgency and impact, and GLPI derives priority from the two values. Priority then drives how the ticket is displayed, sorted and, where SLAs are configured, how targets are measured. Check which fields are visible on your ticket form and whether your templates make them mandatory, because a missing urgency value leaves the calculation with nothing to work from. Confirm the default urgency and impact set for each category in your version.

Problems: priority from shared fields

Problem records carry their own urgency and impact fields, and GLPI computes a priority for each problem the same way it does for tickets. Problems are usually opened by a technician after several tickets point to one cause, so the values reflect the root cause's effect rather than a single user's request. Decide whether a problem's priority should be raised when linked tickets are escalated. Confirm in your version whether the problem matrix is the same table as the ticket matrix.

Changes: priority and approval paths

Change records also use urgency and impact to compute priority, and that priority often determines who must approve the change. A high-urgency, high-impact change may need a different validation path from a routine one, so the matrix on changes affects governance as well as queue order. Confirm which fields your change form exposes and whether any business rules or validation steps read the computed priority before you rely on it for routing.

Urgency and impact fields: the shared inputs

Urgency and impact are the two inputs every object type reads, so a change to their labels or their available values affects the whole service desk at once. Review the dropdown values with your service owners before go-live, since renaming or hiding a value can break existing reports and saved searches. Confirm whether your GLPI version lets you set the matrix once for all object types or per type, and record the answer in your configuration document.

Matrix scope: shared or per object

The central decision is whether one matrix serves tickets, problems and changes or whether each object type gets its own grid. A shared matrix keeps reporting consistent, while separate grids let change management use stricter thresholds than the help desk. Test both paths in a non-production instance with sample records for each object type. Confirm the answer for your exact version, because the behavior has changed across GLPI releases and this page does not assume one configuration.

Matrix options and when each one fits the service desk

This table compares four ways to set up GLPI's urgency and impact priority matrix, from keeping the defaults to mapping the matrix to a documented service model. Read each row as a decision: the fit column shows the situation, the technician and reporting column shows what changes after the choice, and the verification column lists what to check in the admin screens of your target GLPI version before you commit.

Option	When it fits	What it changes for technicians and reporting	What to verify in the admin screens
Keep the default matrix	Small service desks with a short list of request types and no written priority policy yet	Technicians pick urgency and impact on each ticket and GLPI derives priority from the standard grid. Reports group by the same priority values everyone already sees.	Confirm the default priority values for urgency and impact in the target version, and test one ticket of each combination to see the resulting priority.
Adjust individual urgency and impact combinations	Teams that agree certain pairs, such as high impact with low urgency, should land on a different priority than the default grid gives	Changes priority for specific combinations only, so existing tickets may shift priority after edits. Reports and SLA targets tied to priority will reflect the new mapping.	Check the priority matrix configuration page, record the original grid before editing, and confirm which SLAs and escalations key off priority so their targets still match your service model.
Disable unused urgency or impact levels	Desks that only use three levels, or that want to stop technicians from choosing values the process never uses	Removes unused values from the drop-down choices on tickets, problems and changes, which reduces data entry mistakes. Historical records that already used a disabled value keep their stored value, so reports need a check.	Confirm the setting applies to tickets, problems and changes as you expect, and test that a disabled level no longer appears on new forms while old tickets still display correctly.
Map the matrix to a documented service model	Organizations with a written priority policy, defined response targets and separate handling for problems and changes	Each priority value gets a stated meaning, owner and target, so technicians apply the same rules and managers can compare results across teams. Problems and changes can follow the same grid, which keeps change routing consistent.	Compare the GLPI grid line by line with your approved policy, confirm the labels and colors match the document, and verify that SLA and OLA definitions reference the same priority values you publish.

Tying the GLPI priority matrix to SLA targets

Priority matters because the service desk often uses it as the input for choosing which SLA, OLA and escalation behavior applies to a ticket. In GLPI, urgency and impact feed the computed priority, and that priority is one of the values the rest of the service desk may read. A change to the matrix can therefore change which targets a ticket receives, even when nobody edits an SLA. Before you change the matrix, identify every SLA, OLA and escalation rule that reads priority, because those are the places where a matrix edit has consequences beyond the ticket form.

Confirm the link in the target version rather than assuming it. Review the SLA and OLA definitions and the escalation levels in your own instance, and check whether each one selects its target by priority, by category, by request type or by a combination of these. Also check any business rules that set SLA fields or priority directly, since a rule that overrides the computed value can make a matrix change look like it had no effect. Record the exact mapping in a short table for your team. Confirm the behavior with the GLPI documentation for your release, and with your own test instance if the rules are complex. The GLPI installation docs cover upgrade steps, which matter if the priority behavior changes between versions.

Test a sample of tickets before and after the change. Choose representative tickets across categories, entities and request types, note the priority, SLA, OLA and escalation values each one carries, then apply the matrix change in a non-production instance and compare the results. Pay attention to open tickets, because their targets may not recalculate the same way as new tickets. Repeat the comparison after the change reaches production and keep the results with the change record. Any ticket whose target moved without a deliberate decision should be treated as a defect in the change plan. For the setup of the targets themselves, including calendars, TTO and TTR values and pending status, see the sibling topic on setting up SLAs and OLAs in GLPI.

Configuring the GLPI priority matrix step by step

This sequence agrees what urgency and impact mean for your service desk, sets the matrix that turns them into priority, removes levels nobody uses, and proves with test records that tickets, problems and changes compute the priority you intended.

Agree urgency and impact definitions
Before anyone touches GLPI, the service desk lead, the change manager and a representative from each support group write down what each urgency and impact level means in practice, with one example of a qualifying incident for each. Record the agreed grid on a single page that the approvers sign off. You know this step is done when every level has a plain-language definition and the group can apply it to three past tickets with the same answer.
Back up the database and configuration
Before editing any matrix values, the administrator takes a full database backup and copies the GLPI files and config directory, including the glpi.key and glpicrypt.key files. Store the copy somewhere the editing account cannot overwrite. You know this step is done when a restore of the backup has been tested on a non-production copy, or when your team has confirmed the backup job completed and can be read back.
Set the priority matrix values
In the GLPI administration area, open the priority configuration for tickets, problems and changes. Confirm the exact menu path in your GLPI version, since labels move between releases. Enter the priority that each urgency and impact combination should produce, matching the grid signed off in the first step. Save each object type separately and keep a screenshot or export of the grid. You know this step is done when the saved values match the signed-off grid cell for cell.
Disable unused urgency and impact levels
Where the service desk does not use certain urgency or impact levels, disable them in the dropdown configuration rather than deleting them, so historical tickets keep their values. Confirm that the levels are still referenced by existing records before disabling. Then check that the ticket, problem and change forms no longer offer the disabled levels to new users. You know this step is done when a new ticket form shows only the agreed levels and existing records still display their original values.
Create test tickets across the matrix
Create a set of illustrative test tickets, one for each cell or for a representative sample covering every row and column of the grid. Use a test entity or a test account so that notifications do not reach real users. Record the urgency and impact entered, then the priority GLPI displays. You know this step is done when every sampled ticket shows the priority the grid predicts, and any mismatch has been traced to a configuration value and corrected.
Confirm priority on problems and changes
Repeat the test on problems and changes, because each object type uses its own matrix and the values can differ. Create at least one test record of each type with a combination that the grid places at a high priority and one at a low priority. Compare the computed priority with the agreed grid. You know this step is done when problems and changes both match the signed-off values, and a short note records which tests were run and by whom.
Record the result and retire test data
Export the final matrix configuration and the test results into your change record. Remove or close the test tickets, problems and changes according to your retention rules, and confirm that the test notifications were not sent to live recipients. Ask the service desk lead to re-run two or three tickets after the first live week. You know this step is done when the change record links the signed-off grid, the test evidence and the cleanup confirmation.

Who signs off, who edits and who reads the matrix

Service desk managers own the grid itself: which urgency and impact levels exist, how they combine into priority, and which response and resolution expectations each priority carries. They sign off on changes because every SLA, OLA, escalation and routing rule that reads priority inherits the result. Before approving an edit, they should review the current distribution of tickets by priority, the SLA definitions that depend on it, and any escalation rules that fire on priority values.

Level definitions: Write one sentence per urgency and impact level that states who chooses it and what evidence supports it.
Priority ladder: Agree how many priority levels the desk works in practice, and which urgency and impact combinations should land on the same priority.
Target ownership: Confirm with the SLA owners which response and resolution targets change when a priority moves.
Change record: Require a written record of the old grid, the new grid, the effective date and the approver before any configuration work starts.

Before sign-off, check that every SLA, escalation and routing rule that reads priority still produces the outcome the desk agreed to.

Disabling priority levels the service desk does not use

Hiding priority levels that the service desk never assigns cuts selection errors and clutter. When a dropdown on a ticket, problem or change offers five priorities but the team only ever uses three, agents pick between near-identical values and reporting fills with levels nobody works from. Before you disable a level in GLPI's priority settings, decide which levels your urgency and impact combinations can actually produce, because the priority matrix will still compute a value from them. Disabling a level removes it from new selections and from filter lists, but it does not rewrite the records that already carry it. Confirm with your service owner that every combination of urgency and impact still maps to a level you intend to keep, so no new record ends up with a value that is hidden from the people who must triage it.

Open records that already hold a disabled priority keep that value, and you should verify how they display. Check a sample of open tickets, problems and changes that carry the level you plan to disable, and confirm in a test instance that the item still opens, shows its priority and can be updated without a validation error. Then review everything that filters by priority before you change anything: saved searches, report and statistics filters, dashboards, and automatic actions or business rules that set or test a priority value. Each of these may silently return fewer results once a level disappears from its selection list, so list them with their owners and decide whether to repoint them to the remaining levels. Reports that compare historical periods deserve particular attention, because they will mix retired and current values.

Plan the change as a dated cutover that you can test and explain. Agree with the service desk what happens to in-flight records, for example whether a team will reprioritize open items manually or accept the old value until closure. Ask your partner or internal administrator to confirm the exact behavior of disabled dropdown values in your installed GLPI version, since the release notes and documentation may differ by release, and test it on a copy of production data. Communicate the new option list to agents and requesters, and keep a short record of which levels were disabled, when and why, so auditors and managers can trace later changes to the priority scale.

Operational risks when the GLPI priority matrix changes

Changing how urgency and impact compute priority touches open tickets, reporting history, administrator access and the SLA and escalation behavior that depends on priority. The four risks below share one cause: a configuration edit that looks local but reaches live service desk work. Confirm each control against the GLPI version you run before you rely on it.

Changing the matrix while tickets are open

Priority is calculated from urgency and impact, so an edit to the matrix can change the priority shown on tickets that are already in progress. Open tickets may move to a different priority, and any SLA or escalation tied to that priority can start running against a new target. Before the change, list open tickets grouped by current priority, and schedule the edit for a quiet window when the queue is smallest. Confirm with your version's documentation whether existing tickets are recalculated automatically or only when they are next updated.

Breaking historical comparisons in reports

Monthly and quarterly reports often group tickets by priority, so a changed matrix can make this year's "high" tickets look different from last year's. Trend lines may show a shift that reflects configuration, not service performance. Export a baseline of ticket counts by priority, urgency and impact before the change, and record the matrix version in the same file. Ask the report owner which dashboards filter on priority so they can annotate the change date.

Permission gaps for configuration edits

Matrix settings sit in administrative configuration, and an account with broad profile rights can change them without service desk approval. Untrained users who edit priority levels or disable them can silently alter routing and SLA outcomes for every entity. Review which profiles can reach dropdown and priority configuration, restrict edit rights to a small named group, and confirm in your version how those rights are granted. Test the restriction with a non-administrator account before relying on it.

Unannounced changes to SLA and escalation

Business rules, SLA definitions and escalation levels may reference priority, so an edit to the matrix can change which SLA applies or when an escalation fires without anyone updating those rules. Support teams then see different response expectations with no explanation. Before editing, list every SLA, OLA, escalation and business rule that reads priority, and write the expected outcome for a sample ticket of each priority. Announce the change to the service desk and to the groups receiving escalations, and file a change record with the before and after values.

What configuring the GLPI priority matrix costs and needs from your team

What drives the effort of configuring the GLPI priority matrix?

The effort depends on how many urgency and impact levels your service desk actually uses, how many item types need the matrix (tickets, problems and changes), and how many entities or teams share one GLPI instance. A small single-entity desk that keeps the default levels is a short configuration task. A multi-entity deployment where each customer expects different priority rules, and where change approvals depend on priority, takes longer because each variant needs a decision, a test ticket and a sign-off. Ask any provider to break the work down by item type and entity.

Can an internal GLPI administrator configure the priority matrix alone?

Yes, in most organizations an administrator who knows the service desk's urgency and impact definitions can change the matrix in GLPI's administration settings. The harder part is agreeing on the definitions with managers, customers and change authorities before anything is changed. Your administrator should also check how priority feeds SLAs, escalations and business rules, because a matrix change can shift which targets apply. If nobody on the team has tested ticket creation across entities, that testing is the step most often skipped.

How long does a typical priority matrix change take to plan and test?

No fixed duration is supplied for this work, so treat any timeline as provisional until the scope is written. The planning time depends on how many stakeholders must agree on urgency and impact labels, and the testing time depends on how many combinations of urgency and impact you need to verify across ticket, problem and change forms. Ask for the planning, build and test steps as separate line items so you can see where time goes and what happens if a stakeholder review adds a round.

What does the consultant need from our team before starting?

Prepare the current urgency and impact definitions, the list of priority levels your teams really use, and the SLA and escalation rules that depend on priority. Also provide a sample of recent tickets, problems and changes, the names of the approvers for priority decisions, and a test or staging GLPI instance where changes can be checked before production. Access to the GLPI administration profile and a named contact who can decide on disputed levels will keep the work moving.

Which parts of the priority matrix work are one-time and which recur?

The initial definition of urgency and impact, the matrix build and the first round of testing are one-time work. Recurring work follows from how the service desk changes: new services, new customer tiers, and reviews of how often priority is overridden by hand. Disabling unused levels is usually one-time, but reviewing whether the levels still match practice belongs in your regular service review. Ask the provider which parts are included in the fixed scope and which would be a separate retainer.

What should we ask for in a fixed-scope quote for this work?

Ask for a written scope that names the GLPI version and environment, the item types covered (tickets, problems and changes), the number of urgency and impact levels before and after the change, and the entities affected. Also ask which SLAs, escalation levels and business rules are checked for side effects, what testing is delivered and how results are recorded, what documentation is handed over, and what happens if the agreed definitions change during the work. DeployOpen quotes follow from the written scope, so a clear scope document is the basis for comparing offers.

What goes wrong when the priority matrix is changed without testing?

Changing urgency or impact levels without testing can alter the priority of existing tickets, shift which SLA applies, and break routing or escalation rules that depend on priority. Disabling a level that some forms or saved searches still use can leave tickets with a value nobody can select. Test with representative tickets in each entity, check the SLA and escalation outcome for each priority, and keep a record of the previous configuration so it can be restored if needed.

Limits to confirm in your GLPI environment

The priority matrix sits between urgency, impact, SLAs, escalations and any plugins you run, so a change in one place can shift the others. The cards below list the behaviors to confirm on a test instance before you publish a matrix to production users.

Exact matrix behavior by version

Confirm how the installed GLPI version computes priority from urgency and impact, which levels it offers and how many steps the grid has. Release behavior changes between major lines, and the GLPI 11 and 12 series both carry updates that affect ticket forms. Build a sample ticket for each urgency and impact pair and record the resulting priority. Ask your GLPI administrator or Teclib' documentation for the authoritative grid, and check it on a test instance before you accept it.

Shared or per object type

Find out whether tickets, problems and changes read one matrix or separate grids that you can tune independently. A shared grid means one change alters all three object types, while separate grids let a change board use different priority logic from the service desk. Create one test object of each type with identical urgency and impact, then compare the priorities. Confirm the answer with the vendor documentation for your version rather than assuming symmetry.

Interaction with SLAs and escalations

Check whether a priority change recalculates the SLA target or only the displayed value, and whether an escalation rule that sets priority fires before or after the SLA clock is evaluated. Pending status and calendars can also move deadlines in ways that look like priority problems. Run a ticket through a change in urgency while an SLA is active, then review the time-to-own and time-to-resolve values. Ask the team that owns your SLA design to sign off on the test result.

Plugins and custom fields

Identify every plugin and custom field that reads or writes urgency, impact or priority, including forms, business rules and approval tools. Any of them can override the matrix value on save, on import or on a specific ticket type. Export the list of active plugins from the administration area, then test each one against your grid. Ask the plugin publisher or your integration partner to document which fields they set, and retest after every upgrade.

How DeployOpen works on this

DeployOpen scopes the GLPI priority matrix as a written piece of work covering urgency, impact and the levels your service desk actually uses for tickets, problems and changes. The work runs inside infrastructure you control, with each setting traced back to a decision your service desk has agreed.

How we scope

Inventory the urgency and impact levels your teams use today across tickets, problems and changes.
Agree which priority levels stay enabled and which unused levels will be disabled.
Record the matrix values, owners and approval path in the written scope before work starts.
Confirm which GLPI version and upgrade path your instance is on before changing matrix values.

How we build

Configure the urgency, impact and priority mapping in a non-production GLPI instance first.
Test sample tickets, problems and changes to confirm each combination yields the agreed priority.
Check how the matrix interacts with SLA definitions, business rules and ticket templates in use.
Review the configuration with service desk leads before promoting it to production.

How we hand over

Deliver a documented priority matrix showing every urgency and impact combination and its result.
Provide a change record listing the disabled levels and the reasons they were removed.
Walk your administrators through the test cases so they can repeat them after future changes.
Hand over the configuration export and rollback steps alongside the written documentation.

How we support

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
Ongoing support, upgrades and continuous testing are available as a retainer for your GLPI estate.
Re-check the priority matrix during each GLPI upgrade, since plugins are suspended after a new version is detected.
Ask your DeployOpen contact to confirm retainer terms and what they cover for matrix changes.