When a service desk needs group escalation in GLPI
Consider the Escalade plugin when a ticket has to move between first-line and second-line groups as a team hand-off, and managers need to see which groups have held it. Standard assignment and escalation rules can reassign individuals, but a service desk that thinks in queues often needs the group itself to be the unit of escalation. Before building anything, list the group hand-offs your process actually uses, who approves them, and which reports managers will check to confirm that a ticket passed through the right teams.
According to the topic's scope, the plugin is meant for three things: escalating to a group without naming a single assignee, keeping a visual history of the groups a ticket has been assigned to, and returning a solved ticket to the first-line group. Confirm each of these in the plugin's own documentation for your version, including what triggers an escalation, whether it can be automated, and how the history appears to users who only see the ticket and not the plugin settings. Do not assume that a feature on a plugin page works the same way on the ticket form for every profile.
The plugin is usually scoped as its own workstream because it adds code to a production helpdesk. Match the plugin version to your GLPI release, which you can check on the GLPI releases page, and plan a test instance first. Since GLPI 11.0, plugins are suspended after a new version is detected and must be reactivated after major updates, so schedule that step in your upgrade plan. Ask for the test cases you will sign off, including a solved ticket returned to first line and a reopened ticket that moves again.
What the Escalade plugin does for group handoffs
The Escalade plugin targets the handoff between support groups, which GLPI's standard assignment logic does not model as a first-class step. The cards below cover the capabilities to scope, the behavior to verify in a test instance, and how the plugin sits alongside business rules and SLA escalations.
Group-only escalation
The core need is moving a ticket from one support group to another without treating the handoff as a full reassignment to a person. Confirm in the plugin documentation whether an escalation changes only the assigned group, or also clears the technician, status or priority, and which profiles can trigger it. Test the handoff on a ticket that already has a technician assigned, since that is where handoffs usually fail.
Visual history of assigned groups
Each handoff should leave a readable trail on the ticket. Confirm where the plugin displays the history, whether it records every group change or only escalations triggered by the plugin, and whether the record stays attached when a ticket is archived or purged. Ask the vendor how the history is stored, since it affects backups and reporting on how many groups touched a ticket.
Returning solved tickets to first line
Solved tickets sometimes need to go back to the first-line group for confirmation or closure. Confirm whether the plugin reopens the ticket, changes only the group, or leaves the status unchanged, and how that interacts with the solution step and satisfaction surveys. Check whether the return resets or pauses the SLA clock, because a silent change here can distort compliance figures.
Fit with business rules and SLA escalations
GLPI business rules, ticket templates and SLA escalation levels can also set assignees and groups, so two mechanisms may compete for the same field. Decide which one owns group changes for each category, then confirm the rule order and whether a plugin-driven change re-triggers business rules. Use a test entity with one category and one escalation path before extending the design to production.
Plugin lifecycle across upgrades
Since GLPI 11, plugins are suspended after a new version is detected and must be reactivated after major updates. Confirm that the Escalade release you run supports the GLPI version you plan to move to, including GLPI 12, before scheduling an upgrade. Include a post-upgrade check that the group history and return actions still work, because a suspended plugin can look like a working plugin in the ticket screens.
When business rules are enough and when escalation needs a plugin
Business rules handle the handoff when the destination can be decided from ticket data at the moment the ticket is created or updated. A rule that reads the category, entity, urgency or location and assigns a group or user covers most first-line routing, and it keeps the decision in one auditable place. The question to settle before adding a plugin is whether the handoff is a one-time routing decision or a sequence of movements that depends on what has already happened to the ticket. If the service desk can name the target group in advance and does not need to remember where the ticket has been, business rules and the escalation levels workstream are usually the right tool. Confirm the exact rule actions and criteria in your GLPI version before you design around them, because the available options differ between releases.
A plugin becomes worth evaluating when the team needs group-level movement, a visible trail of earlier groups, or a defined return path for solved tickets. Rules set the current assignment, but they do not by themselves show that a ticket spent two days with level 1, moved to a platform group, and came back for a fix. Teams that report on handoffs, audit who held a ticket, or want level 1 to receive the ticket again after a level 2 fix will find that assignment alone loses that history. Before committing to the Escalade plugin, list your real escalation paths, write down which of them must be reversible, and confirm with the plugin's documentation that it supports the group-only and return behaviors you need on your GLPI version. Plugin support for a given GLPI release should be checked directly with the plugin's publisher.
Configuration decisions before you enable group escalation
This table compares the choices to settle before enabling group escalation: who may escalate, what triggers the hand-off, how history is read, where solved tickets return and how entities and profiles limit visibility. Test each row against your service desk model in a non-production instance, and confirm the default behavior of your plugin version in its documentation before you rely on it.
| Decision | Option | When it fits | What it changes for agents and reporting |
|---|---|---|---|
| Who can escalate | Members of the currently assigned group only | Teams that need a clear owner at every step | Agents in other groups cannot move the ticket, so hand-offs stay with the group holding it |
| Trigger | Manual escalation by an agent | Cases where the agent judges the hand-off, not a fixed condition | Each hand-off depends on agent action, so reports reflect what agents chose to record |
| Trigger | Escalation driven by a business rule | Repeatable criteria such as category, priority or ticket age | Rules must be tested, and escalation only fires when the conditions match in your rule order |
| Group history for agents | History shown on the ticket | Agents who need to see earlier groups before they act | Agents can read prior hand-offs without asking; confirm how the visual history appears on each ticket view |
| Group history for managers | History read through reports or saved searches | Managers who compare hand-offs across many tickets | Confirm whether the history can be filtered or exported, and plan a report if it cannot |
| Return of solved tickets | Return to the first-line group that opened the ticket | Service desks where first line confirms the user is satisfied | First line closes the ticket, so resolver groups see fewer closure steps |
| Return of solved tickets | Stay with the last resolver group | Teams where the resolver must confirm the fix and close | The resolver keeps ownership until closure, and first line sees less of the outcome |
| Entity scope | Escalation limited to groups in the same entity | Multi-entity deployments with separate customers or departments | Confirm whether cross-entity hand-offs are blocked, and plan another path if they are needed |
| Profiles and visibility | Escalation right granted to specific profiles | Organizations that limit who can move work between groups | Agents without the right cannot escalate; confirm the right name and scope in your GLPI version |
Rollout sequence for group escalation
This sequence takes group escalation from a version check to a trained service desk, with each step producing a record the team can review before the next one starts. It keeps the test work on a non-production instance and uses pilot tickets to prove both the group history and the return path.
Confirm plugin and GLPI version compatibility
The platform engineer checks the Escalade plugin release against the GLPI version in production and in the target upgrade path, using the plugin's own compatibility notes and the GLPI release notes. Because GLPI suspends plugins after a new version is detected, the team also records which plugin version pairs with each GLPI release it plans to run. The output is a compatibility record that names the GLPI version, the plugin version and the upgrade order.
Define groups and entity structure
The service desk lead and the GLPI administrator list the first-line, second-line and specialist groups, decide which entities they serve, and map which groups may escalate to which others. They confirm that each group is a real assignment target in every entity where tickets will move. The output is a signed-off group and entity map that lists every allowed escalation path.
Configure escalation on a non-production instance
The administrator installs the plugin on a non-production copy of the GLPI database and files, sets up the group-only escalation options, and checks that the configuration applies to the entities from the previous step. The change is documented in a configuration record that lists each setting, its value and its owner. The output is a tested configuration record that can be replayed on production.
Test escalation and return with a case list
The QA owner runs a written test case list covering escalation to a group, escalation to a group in another entity, a second escalation of the same ticket, and a return to the first-line group after the solution is recorded. Each case states the expected assigned group, the expected history entry and the expected status. The output is a signed-off test case list with pass or fail results and retest notes.
Validate group history with pilot tickets
The team runs a small set of pilot tickets through real queues on the staging instance, checking that the visual history shows every assigned group in order and that reports read the history correctly. It also confirms that business rules and SLA fields do not reset when a ticket moves between groups. The output is a pilot results sheet that records each ticket, the history captured and any defects to fix before go-live.
Apply the configuration to production
The administrator applies the tested configuration record to production during an agreed change window, following the backup and plugin reactivation steps in the GLPI update procedure. A production smoke test repeats two cases from the test list to confirm that the live settings match staging. The output is a change record with the backup reference, the configuration version and the smoke test result.
Train agents and set a review point
The service desk lead briefs first-line and escalation agents on when to escalate to a group, what the history shows and how solved tickets return to first line. The team agrees a review date and the metrics it will check, such as escalations that bounced between groups. The output is a training attendance list, a short agent guide and a documented review point owned by a named person.
What drives effort and cost for escalation work
This table lists the factors that move the effort and cost of group escalation work in GLPI, and what each one does to the scope. Read each row as a question to answer before asking for a quote, because the same escalation design can cost very different amounts depending on the size of the instance and the rules around it. The main takeaway is that the number of groups, existing assignment rules and migrated open tickets matter more than the plugin itself.
| Driver | How it changes cost or effort | What to ask for in a written quote |
|---|---|---|
| Support groups and entities | Each first-line, second-line and specialist group needs its own escalation path, visibility and test cases. More entities multiply the group structure and the profiles that must be checked in each. | A list of groups per entity, the escalation path for each, and which groups can see which tickets. |
| Existing business rules touching assignment | Rules that set assigned groups, technicians or categories can conflict with escalation steps. Each overlap needs analysis, reordering and regression testing. | An inventory of current assignment rules, the ones to retire or keep, and the test cases used to confirm the order of execution. |
| Open tickets to migrate or reconcile | Open tickets with a history of assigned groups must be checked so the visual history reads correctly. Large backlogs add data validation and exception handling. | The count and status of open tickets in scope, the source of the history data, and how exceptions are reviewed and signed off. |
| Custom profile and visibility design | Returning solved tickets to the first-line group depends on profile rights and visibility. Custom profiles and restricted views add design, review and access testing. | A profile matrix covering who can escalate, reopen, solve and view history, with the approver for each role. |
| GLPI and plugin upgrades | The Escalade plugin must be verified against each GLPI version and plugin update. Plugins are suspended after a new GLPI version is detected and must be reactivated after major updates, so each upgrade repeats part of the test cycle. | The GLPI and plugin versions in scope, the expected upgrade cadence, and whether regression tests for escalation are included in each upgrade. |
| Testing and acceptance | Escalation paths need scripted tests for each group, each direction of escalation and the return to first-line. More paths and more edge cases raise the testing effort. | The test scenarios included, who runs them, and the acceptance criteria written before work starts. |
| Subscription or support tier | If the team plans to use GLPI Network services, the subscription tier and support level are a separate cost line that recurs. Confirm which services are included before comparing quotes. | The subscription tier named in writing, whether support is included, and the renewal terms, if any. |
How escalation connects to the rest of the GLPI platform
Group escalation does not sit alone in GLPI. It depends on business rules, SLA and OLA timing, notifications, directory-sourced group membership and manager reporting, so a change in one area can shift who sees a ticket and when. Check each connection in a staging copy before you change production.
Business rules set the first group
Business rules decide the initial assignment, category and entity for a new ticket, so they define the group that escalation starts from. If a rule changes the assigned group after the Escalade plugin has recorded history, the visual history and the first-line return target can disagree. Test a sample of tickets from each category, and confirm rule order after every rule edit.
SLA and OLA clocks
Escalation moves tickets between groups, but the TTO and TTR clocks belong to the SLA and OLA objects attached to the ticket. A handoff that changes the group may not change the OLA that applies, so the new group can inherit a running or paused clock. Confirm which OLA is active after each escalation step and check pending status behavior in a test ticket.
Escalation levels and reassignment
GLPI escalation levels can reassign, reprioritize or notify when a deadline approaches. Running them alongside group escalation risks two automated actions moving the same ticket. Define which mechanism owns group changes, add criteria so levels fire only on untouched tickets, and log both paths in the test plan.
Notifications that announce handoffs
Receiving groups learn about an escalation through notifications and the notification queue, not from the plugin screen alone. Check that the notification template names the new group, that recipients resolve to group members, and that mail is actually sent. After a major upgrade, confirm these templates and the queue still deliver.
Group membership from directories
Escalation targets are only useful when group membership is correct. Where users come from LDAP directories, the internal database or another external source, membership changes in the directory affect who receives escalated tickets. Test that a user added to an escalation group in the directory appears in GLPI after the next synchronization, and that departed users are removed.
Upgrades and plugin reactivation
Escalade must be compatible with the GLPI version you run, so confirm plugin support for GLPI 11 and 12 before planning an upgrade. Since GLPI 11.0, plugins are suspended after a new version is detected and must be reactivated after major updates. Schedule reactivation as a checked step, then rerun escalation tests on a copy of the production database.
Questions teams ask before setting up group escalation
Do we need the Escalade plugin if we already use business rules?
Not always. Business rules and SLA escalation levels cover many reassignments that depend on time, category or ticket criteria, so start there. The Escalade plugin becomes worth evaluating when you need escalation that moves a ticket between groups without changing the individual assignee, or when you want a visible history of which groups have held a ticket. Map your current escalation paths against both options before you decide. The sibling workstreams on SLA escalation levels and business rules for ticket routing explain where the core engine stops.
How long does group escalation setup take?
No duration can be stated from the researched facts, so ask for a timeline in writing rather than relying on a general estimate. The main drivers are the number of groups and escalation paths, how many business rules already exist and must be reviewed for conflicts, the number of test scenarios your service desk requires, and how quickly your staff can confirm the expected behavior. Installation itself is usually the smaller part. Confirm the plugin's own documentation for setup steps and any prerequisites that apply to your GLPI version.
Can our own team configure group escalation without a partner?
Yes, if your team has an experienced GLPI administrator and a non-production instance to test on. The work involves defining escalation paths, deciding which groups may receive tickets, checking how the plugin interacts with existing rules and notifications, and writing test cases for each path. Teams without prior experience with GLPI rule order or SLA behavior usually take longer and are more likely to create conflicts in production. A fixed-scope engagement can cover the design and testing while your staff keep ownership of the result.
What does the work need from our staff?
Expect to commit time from four groups of people. The service desk lead defines the groups, escalation paths and the conditions under which a ticket should move. A GLPI administrator builds the configuration and owns the test instance. Someone from your mail or identity team is needed if escalation triggers notifications that depend on mail flow or directory data. A service desk representative should approve test results and confirm that agents will see the history they need. Agree on these owners and their review dates before work starts.
How do plugin upgrades affect group escalation?
Upgrades are a planned risk, not an afterthought. In GLPI 11, plugins are suspended after a new version of GLPI is detected and must be reactivated after major updates, so escalation can stop working until someone checks it. Before any upgrade, back up the database, the files and the config directory, including glpi.key and glpicrypt.key, as described in the GLPI update documentation. Then confirm that the plugin version supports your target GLPI release, which may be the 11 or 12 line, and retest the escalation paths after the update.
What breaks when escalation moves tickets between groups?
The most common problems are conflicting business rules that reassign the same ticket twice, notifications sent to the wrong group, and SLA or OLA clocks that behave differently after a group change. Check rule order, confirm which rules run first, and verify how pending status interacts with each escalation step. Test tickets that are already solved, tickets waiting on a requester, and tickets that cross entity boundaries. The SLA and OLA workstream and the business rules workstream describe the checks in more detail.
What should we ask for in a quote?
Ask for a written scope that names the groups and escalation paths in scope, the GLPI version and environment the work targets, the number of test scenarios, and the documentation delivered at handover. Also ask whether upgrade support for the plugin is included, what happens if a GLPI upgrade is planned during the engagement, and whether post-go-live support is a separate retainer. DeployOpen does not publish a price list, so a quote follows from that written scope. Compare quotes on the same scope rather than on headline totals.
How DeployOpen scopes and delivers GLPI escalation work
DeployOpen plans, configures and hands over group escalation for GLPI inside infrastructure you control, starting from a written scope that names the groups, tickets and escalation paths involved. The work covers the Escalade plugin, the business rules and notifications around it, and the documentation your service desk needs to run it after handover.
How we scope
- Map the first-line, second-line and third-line groups, and which ticket types may move between them.
- Record which group transitions are allowed, who may trigger them, and what must be reviewed first.
- Agree the GLPI version and plugin version in writing, including the plugin compatibility check for the target release.
How we build
- Configure the Escalade plugin settings for group-only escalation and confirm the visual history of assigned groups.
- Set up the return path so solved tickets go back to the first-line group with the intended status and notifications.
- Test each escalation and return case in a non-production instance using agreed sample tickets and named test users.
How we hand over
- Document the escalation flow, group responsibilities and the steps a technician follows when escalating or returning a ticket.
- Walk your service desk leads through the history view so they can audit which groups held a ticket and when.
- Record the configuration, plugin version and upgrade notes so your team can repeat the setup after a GLPI update.
How we support
- Ongoing support, upgrades and testing are available as a retainer, scoped in writing alongside the initial work.
- Plugin behavior is re-tested after each GLPI or Escalade plugin update before it reaches production.
- Ask any provider, including us, to confirm the plugin's supported GLPI versions and its maintenance status before committing.
