GLPI SLA escalation levels: when untouched tickets need a second push
GLPI escalation levels let the service desk act on a ticket before or after its SLA deadline, either by reassigning it, raising its priority or notifying people. Teams need them when tickets breach because they sit unassigned or unread, not because the team is idle. A ticket that nobody has picked up is the usual reason a service level is missed, and an escalation level is the mechanism that gives that silence a visible consequence. The escalation level only matters when it fires on the right ticket, so the criteria are as important as the action.
The key design choice is whether an escalation only notifies or also changes ownership. A notification-only escalation tells a group lead or manager that a ticket is at risk and leaves the assignee unchanged, which suits teams where a human should decide what happens next. An escalation that reassigns or reprioritizes changes who owns the ticket or how the queue sorts it, which suits first-line queues where an untouched ticket should move to a second group automatically. Reassignment carries more risk: it can bounce a ticket that was about to be worked, so reviewers should confirm which conditions must still be true at the moment the escalation runs.
Escalation levels work alongside the SLA definitions, they do not replace them. The SLA, its calendar and its time-to-own and time-to-resolve targets still decide when a breach is recorded and how compliance is reported. Before configuring any level, confirm the SLA targets with the service owner, then decide which untouched-ticket conditions should trigger which action. The exact options for criteria, timing and actions depend on your GLPI version, so check them in the administration screens of the version you run and test each level on a non-production copy of the data.
Which criteria stop an escalation from firing on active work
An escalation level is only as good as its criteria. The timer on an SLA decides when a level becomes due, but the criteria decide whether the action runs at all. A reassignment, reprioritization or notification that fires on a ticket an engineer is already handling creates noise, can pull ownership away from the person doing the work, and teaches the team to ignore escalation emails. Before any level goes live, decide which ticket states should block it. The usual candidates are ticket status (so solved or closed tickets never escalate), whether an assignee or group is already set (so an untouched ticket is the only target), and the time since the last update or followup (so a ticket that was touched recently is left alone). Each condition should map to a specific working rule your service desk can explain in one sentence.
Pending status needs separate attention. When a ticket is set to pending, GLPI pauses the SLA clock, so a level keyed to the deadline may still look overdue on a ticket that is correctly waiting for the requester. Decide whether a pending ticket should ever escalate, and if so, through which level, because a status-based criterion may suppress more than you intend. The exact field names, operators and available status values differ by version, so confirm them in the escalation level form of the GLPI release you run before you copy any rule from documentation or another instance. Then test each criterion on real ticket states: create tickets that are new and untouched, assigned and active, updated by a followup, pending, and solved, and check which ones the level selects. Only move the level to production when the selection matches the working rules you wrote down.
Which escalation action fits which service desk situation
This table compares the three escalation actions (reassign, reprioritize and notify) and the choice of firing before or after a deadline, using situations a service desk meets every week. Read each row to match the action to the ticket pattern, then check the risk and the verification step before enabling the level.
| Situation | Best-fit action and timing | Main risk | Verify before enabling |
|---|---|---|---|
| First-line tickets with no owner | Reassign to a first-line group, after the TTO deadline | Tickets bounce between groups if the target group has no membership or the criteria match tickets that already have an assignee | Criteria exclude tickets with an assigned user or technician, and the target group has active members in the right entity |
| High-impact tickets that need a senior group | Reassign to a senior group, before the TTR deadline | A senior group absorbs low-value work and the first-line technician loses visibility of the ticket | Impact and priority conditions match only the intended tickets, and the senior group has an agreed handoff rule |
| Tickets that need a warning before a breach | Notify the assigned group or technician, before the TTR deadline | Warnings become noise if they fire on tickets that are already being worked | Notification recipients receive the email, and criteria stop the level once the ticket is updated or set to pending |
| Tickets that are not moving but still have an owner | Reprioritize, after the TTR deadline | Raising priority on an active ticket changes queue order and can distort priority reports | Reprioritization is limited to tickets that have had no follow-up, and the priority matrix is reviewed for the new value |
| Tickets stalled in pending status | Notify the requester's manager or the group lead, after the deadline | Pending status pauses the clock in some setups, so escalation may fire on tickets that should not be counted | Confirm how pending status interacts with the SLA calendar and that the level checks ticket status |
| Breaches that have already happened | Notify management or reassign to a problem group, after the TTR deadline | Late escalation adds people to a ticket that is already lost and may hide the root cause of delay | Post-breach levels are used for review and reporting, and the owner of the follow-up process is named |
How escalation design differs by service desk model
A single-team desk has one group that owns every ticket, so escalation is mainly about time and visibility rather than handoff. Levels usually run in a simple sequence: a notification to the team before the target is missed, then a reprioritization if the ticket is still untouched, and a notification to a manager once the deadline has passed. Reassignment is rarely useful here because there is nowhere else to send the work, so the escalation design should focus on waking the right person up.
- Early warning levels: Fire a notification before the deadline to the assigned user and the group, so the warning reaches someone who can act.
- Reprioritization: Raise priority only when the ticket is still untouched, so a ticket already being worked does not get bumped.
- Manager notification: Send a late-stage notice to a service lead after the deadline, with criteria that exclude tickets in pending status.
- Criteria discipline: Confirm that each level tests whether the ticket has been modified or assigned, not only the elapsed time.
Service owner sign-off is needed for the notification recipients and for any change that alters priority, since priority feeds reporting. Check that a test ticket moves through each level as expected before going live.
A tiered desk has a first-line group that triages and a second-line group that resolves. Here escalation is primarily a handoff: a level reassigns the ticket to the second-line group when first-line has not picked it up, and a later level can notify the first-line lead or the second-line manager. The design question is who owns the ticket at each stage and whether the customer's SLA clock continues to run during the handoff.
- Reassignment to second line: Use a level that moves the ticket to the second-line group only when it is still unassigned or untouched, so active first-line work is not overridden.
- Notification to first-line lead: Alert the first-line lead before the handoff, so a supervisor can intervene first.
- Reprioritization on handoff: Raise priority when the ticket crosses into second line, so the receiving group sees the urgency.
- Ownership checks: Confirm that reassignment does not remove the first-line group from the history the team needs.
Service owner sign-off is needed on the handoff rules, because they define who is accountable at each tier. Multiple OLAs on one ticket and their reporting are covered on a sibling page, so this tab concentrates on the escalation levels themselves.
A multi-entity desk serves several customers or business units, each with its own SLA and sometimes its own calendar and notification contacts. Escalation levels must therefore be scoped so that a rule for one customer never fires on another customer's tickets. The usual pattern is a shared set of level types applied per entity, with recipients and deadlines that differ by customer. Where the customer SLA is contractual, a missed escalation can become a commercial matter, so the owner of each entity should review its rules.
- Entity-scoped rules: Limit each escalation rule to the entity it serves, and test that tickets from other entities are untouched.
- Per-customer recipients: Route notifications to the contacts agreed for that customer, not to a central mailbox by default.
- Shared templates with local values: Reuse the same level structure across entities while varying only deadlines and recipients.
- Contract alignment: Confirm that escalation thresholds match the wording of each customer's agreement before configuring them.
Service owner sign-off is needed for each customer's rules, and the customer or account owner should approve notification recipients. Ask the team to confirm how child entities inherit or override settings in their GLPI version before relying on inheritance.
Setting up escalation levels in a test entity first
This sequence proves that escalation levels fire at the right moment, act on the right tickets and leave touched tickets alone before any change reaches a production entity. Each step ends with a check you can repeat after the configuration moves.
Confirm the SLA and its calendar
Start in a test entity that mirrors the production setup as closely as you can. Open the SLA configuration area in the Setup menu and confirm the SLA you plan to escalate exists, that its time-to-resolve or time-to-own target is the one the service desk expects, and that it points to the calendar that defines working hours for that entity. Confirm menu paths in your GLPI version, since labels move between releases. Check: create a test ticket that uses this SLA and verify the SLA deadline it displays matches a hand calculation against the calendar. If the deadline is wrong, fix the calendar before going further, because every escalation threshold is measured from it.
Define thresholds and actions for each level
Within the SLA, add the escalation levels you need. For each level, set the point in time relative to the deadline at which it runs, whether that is before or after the deadline, and the action it takes: notify a recipient, reassign to a group or user, or change priority. Write the plan on paper first, one row per level, listing threshold, action and recipient. Check: the list you wrote matches what the SLA screen shows for each level, with no duplicate thresholds and no level that fires after the ticket is already closed.
Set criteria that skip touched tickets
The criteria on each escalation level decide which tickets it processes. Add conditions so a level only applies while a ticket is still untouched, for example a status that still means new and no assignment or follow-up yet. Confirm which ticket fields your version exposes as criteria, because the available fields and operators differ between releases. Check: edit one test ticket so that a technician takes ownership, then confirm the criteria no longer match it in the rule preview or during the next test run. A criterion that still matches an owned ticket will escalate work someone is already doing.
Create test tickets in each state
Build a small set of test tickets that cover the states you care about: untouched and overdue, untouched and not yet due, assigned but untouched, and pending or waiting for the requester. Set their dates so each one crosses a different threshold when you run the process. Record the expected result for each ticket in a short table before running anything. Check: the table lists one expected outcome per ticket, including tickets that should not escalate at all. Those negative cases are what show the criteria work.
Run the SLA level automatic action
Escalation levels are processed by a GLPI automatic action rather than instantly when a deadline passes. Open the automatic actions area in the Setup menu, find the action that processes SLA levels, and run it manually from the same screen for the test pass. Then confirm how often it runs on a schedule in your installation, because a long gap between runs changes when escalations appear. Check: the run completes without a PHP or database error in the logs, and the execution record shows the processed count you expected from your test set.
Verify notifications and assignments
Compare each test ticket against its expected result. For every escalation that fired, confirm the notification reached the intended recipient, the assigned group or user changed as configured, and the priority moved to the expected value. Check the notification queue for queued or failed messages if an expected email does not appear, and confirm the test mailbox receives mail from the instance. Check: every ticket matches its row in the expected results table, and the tickets that should have stayed untouched show no change in assignment, priority or notifications.
Repeat the test after any change
Adjust thresholds, criteria or recipients in the test entity, then rerun the automatic action against the same ticket set. Keep a dated record of each change and each run so the reviewer can see what the configuration did at every stage. Check: two consecutive runs on an unchanged configuration produce identical results, which shows the criteria are stable and no ticket escalates twice by accident.
Move the configuration to production entities
Once the test results match, recreate the SLA, levels and criteria in each production entity or copy them where your version supports it. Confirm recipients and groups in each entity point to production people, not test accounts. Schedule a first production run under observation and review its notifications with the service desk lead the same day. Check: a sample of real tickets in production shows escalations that match the test rules, and the test entity's ticket and notification data is removed or retained as your records policy requires.
Keeping escalation from overwriting manual decisions
An escalation level should never silently undo a choice an agent or supervisor made on purpose. In GLPI, escalation levels run as automatic actions against tickets that meet their criteria, and they can change fields such as assigned group, priority or SLA-related values. Business rules can set the same fields when a ticket is created or updated. If a supervisor has deliberately moved a ticket to a specialist group or raised its priority, an escalation rule that matches on age or SLA state may reset that value later. The result looks like a system fault to the agent, and it erodes trust in both the rules and the queue. Before go-live, decide for each escalation level which fields it may change and which manual values it must leave alone.
Review escalation levels together with every business rule that touches assignment, priority, category or SLA fields, because the two engines do not coordinate with each other. A business rule may set a priority at creation, an escalation level may raise it later, and a second business rule on update may set it back. Rule order, the criteria that match a ticket and whether a field was edited manually all affect the outcome, so the final value can depend on timing rather than design. Confirm in your own GLPI version how rule order is evaluated and how the ticket's update history records which rule changed a field, since that history is your main evidence when an outcome surprises someone.
Write a rule inventory before testing anything. List every escalation level and business rule that writes to assignment, priority or SLA fields, with its trigger, its criteria, the fields it sets and its owner. Then build a test matrix with one row per field and one column per scenario: untouched ticket, ticket with manual priority, ticket reassigned by a supervisor, ticket in pending status and ticket already solved. Run each scenario against a staging copy and record which rule wins and whether the manual value survived. Repeat the matrix after every rule change or GLPI upgrade, and treat any cell where a manual value was overwritten as a defect to fix before release.
Security and operational risks of escalation rules
Escalation levels act on tickets automatically, so a misconfigured rule can notify the wrong people, move work out of reach of the right team or stop firing without anyone noticing. The cards below cover the failure modes that matter most for GLPI SLA escalation levels and the control that addresses each one. Review them before going live and again after every change to the rules.
Notification floods erode trust
When escalation levels notify on every stage, users receive so many alerts that they stop reading them. Before go-live, list each escalation level and the audience it notifies, then ask who would act on each message. Keep warnings before a deadline for the assigned technician and reserve manager or customer notices for breaches. Review notification volume during the first weeks, because a rule that looked reasonable on paper can produce a flood once real tickets arrive.
Reassignment outside the customer entity
An escalation that reassigns a ticket to a group that lacks access to the ticket's entity can leave work stranded or expose data to people who should not see it. Check each target group's entity visibility and profile rights before attaching it to an escalation level. Test one ticket per entity, and confirm that the receiving group can open, update and close the ticket without elevated rights.
Automatic actions that stop silently
Escalation levels only run when GLPI's automatic actions execute. If the cron job or the relevant automatic action stops, tickets keep breaching their targets with no alert and no reassignment. Monitor the last run time and error state of the automatic actions that drive escalations, and alert the operations team when they fall behind. Pair this check with the notification queue review so that a stalled queue is visible too.
Notifications to external addresses
Escalation notifications can go to any address a template or recipient rule points to, including personal mailboxes, former staff accounts or external mailing lists. Those messages can carry ticket titles, customer names or internal details outside the organization. Review every recipient type in each escalation template, remove stale or external addresses, and confirm that mailing lists have the membership you expect before they receive ticket content.
Too many people editing escalations
Escalation levels change how work moves and who hears about it, so a broad edit right can alter service behavior without review. Limit edit rights on SLA and escalation configuration to a small named group of administrators, and keep read access for auditors and service managers. Review that group on a fixed schedule and remove rights when people change roles.
Changes made without a test record
An escalation level edited directly in production can fire on live customer tickets before anyone has checked its timing or recipients. Keep a test ticket per scenario, such as a breach, a pending status and a reassignment, and record the result before and after each change. Store the test record with the change ticket so that the next reviewer can see what was verified and what was not.
What to confirm in your GLPI version and environment
Before you commit to an escalation design, confirm the exact GLPI version you run and whether its escalation options match what this page describes. GLPI has moved quickly across releases: 11.0 arrived in October 2025 and 12.0.0 followed in October 2026, according to the GLPI releases page. Option names, the fields available as criteria and the actions an escalation level can take may differ between releases, so read the documentation for your release rather than a newer or older one. Then build one escalation level in a non-production entity, using the same conditions you plan to use in production, and confirm that each action does what you expect.
Next, confirm how the SLA calendar and business hours affect timing. An escalation tied to a deadline is only as accurate as the calendar behind that deadline, so check which calendar each SLA uses, how holidays and closed periods are defined, and whether a pending status pauses the clock in your setup. Also confirm that the automatic action which evaluates escalations runs on the schedule your desk expects, and what happens when it runs late or fails. Test with tickets that cross a closed period, since that is where timing surprises usually appear. The GLPI installation documentation is a useful starting point for how the platform's scheduled tasks are maintained after updates.
Finally, confirm how mail notifications leave your environment and whether any plugin changes ticket assignment. Escalation notices depend on your mail relay, sender authentication and the notification queue, so send a test notice for each escalation type to the mailboxes your team actually reads. Review every installed plugin and business rule that can set the assignee, group or priority, because an escalation that reassigns a ticket can conflict with a rule that runs later. Record the results of these checks, including the GLPI version, calendar settings and test outcomes, so the design is reviewed against evidence rather than assumptions.
Questions buyers ask about GLPI escalation levels
What drives the cost of configuring GLPI escalation levels?
The main cost driver is how many distinct escalation rules the service desk needs, and how many SLAs, entities and groups those rules must cover. Each escalation level needs a defined trigger, a target action (reassign, reprioritize or notify), a recipient, and a test that proves it fires only when it should. A single entity with two SLAs is a small job. Many entities, each with its own calendar, OLAs and notification language, multiplies the design and testing work. Other cost factors include whether existing business rules already route tickets, whether your group structure is settled, and how much documentation you need for auditors or your own operations team. Ask any provider for a quote built from a written list of SLAs, entities, escalation levels and test cases. DeployOpen provides quotes from the written scope, and most engagements are fixed-scope.
Can our own team configure GLPI escalation levels in-house?
Yes, a team comfortable with GLPI administration can configure escalation levels internally, especially for a single entity with a small number of SLAs. The configuration itself lives in the SLA settings, so the work is mostly design and verification rather than technical complexity. The risks sit in the details: an escalation that fires on a ticket someone already picked up, a notification sent to a group that no longer exists, or an action that overrides a manual value an agent set on purpose. Teams that build in-house should plan time for a test matrix, a review of how escalation interacts with business rules, and a second person to check the criteria. If your team lacks time or GLPI experience, a partner can take the design and testing while your staff keeps ownership of the final configuration.
How long does escalation configuration usually take?
Duration depends mainly on the number of SLAs, the number of entities and how many escalation levels each SLA needs. Duration is not published as a fixed figure here, so ask for a timeline in the written scope and check that it accounts for design, build, testing and handover as separate steps. A useful planning split is one block for agreeing the SLA definitions and group structure, one for building the rules, and one for test tickets across time-based and status-based triggers. Multi-entity setups usually take longer because each entity needs its own calendar, notification templates and recipient groups checked. Timelines also shift when stakeholders are slow to confirm SLA targets, so the scope should name who signs off each decision.
What does our team need to provide before escalation work starts?
Before any escalation rule is built, you need four inputs ready. First, written SLA definitions with time-to-own and time-to-resolve targets for each priority and request type. Second, a group structure that shows which teams own tickets at each level, and who should be notified when a ticket goes overdue. Third, working calendars that reflect your business hours, holidays and on-call coverage, since escalation timing depends on them. Fourth, a set of test tickets and test users so each escalation level can be proven in a non-production instance, including tickets left untouched, tickets assigned, and tickets moved to pending. Missing any of these items is the most common reason escalation projects stall. Confirm each input in the written scope before the build starts.
Why must escalation criteria check whether a ticket is still untouched?
Without a criterion that checks whether a ticket has been touched, escalation fires on tickets that agents are already working, which floods managers with false alarms and erodes trust in the notifications. The criteria should check the ticket's status, its assignee and whether a follow-up has been recorded, so an escalation only runs when no one has acted. Test this with tickets that are assigned but idle, tickets set to pending, and tickets solved just before the deadline. Confirm the exact criteria names and behavior against your GLPI version's documentation before you rely on them, because the options available in the SLA escalation settings differ between releases.
Does GLPI escalation need a separate plugin?
Core GLPI includes SLA escalation levels, so most service desks do not need a separate plugin to reassign, reprioritize or notify. A plugin becomes worth evaluating when your model goes beyond what core rules can express, such as group-only escalation with a visual history of assigned groups, or returning solved tickets to a first-line group. Community and vendor plugins also change maintenance work, because each one must be checked at every GLPI upgrade and may need reactivation after a major update. Ask for a written comparison of core escalation against any plugin for your exact use cases, and confirm the plugin's compatibility with the GLPI version you plan to run.
Who maintains escalation rules after the project ends?
Escalation rules need ongoing ownership because SLAs, groups and calendars change over time. Someone on your team should own the rule inventory, review it when an SLA target or group changes, and rerun the test tickets after each GLPI upgrade. Plan for maintenance in the handover: a written record of each escalation level with its trigger, action, recipient and test case, and a named owner for changes. Upgrades matter here, since GLPI suspends plugins after a new version is detected in some update paths, which can silently disable plugin-based escalation. Ask any partner what handover documents and retest steps are included, and whether ongoing support is offered as a separate retainer.
How DeployOpen works on this
DeployOpen plans, implements, customizes, documents and supports self-hosted GLPI inside infrastructure you control. For escalation levels, we start from your written SLA and ticket flow, then build and test each escalation step against the criteria that stop it firing on tickets someone has already picked up.
How we scope
- Map which SLAs and OLAs need escalation levels, and which ticket types and entities each level covers.
- Write down the trigger points, the actions for each level (reassign, reprioritize or notify) and the recipients.
- Agree the untouched-ticket criteria in writing, so the scope names exactly what counts as no action taken.
- Engagements are fixed-scope, with deliverables and timelines agreed before work starts.
How we build
- Configure escalation levels on a test instance first, with each action tied to a named SLA and calendar.
- Test each level against sample tickets that are untouched, assigned, pending and already solved.
- Check notification queues and the escalation automatic action so alerts reach the intended recipients.
- Record the configuration choices, including any criteria that depend on your GLPI version.
How we hand over
- Deliver a written configuration record listing each escalation level, its trigger, criteria and owner.
- Provide a test script your service desk can rerun after changes to SLAs, groups or categories.
- Walk your administrators through the rules, the logs to check and the cases that need a manual decision.
- Confirm which items are in the handover and which remain with your team.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer.
- Retested escalation rules after a GLPI minor update or major upgrade, including plugin reactivation checks.
- Ask any support partner to confirm response coverage and how changes to escalation rules are approved in writing.
