How multiple OLAs on one GLPI 12 ticket support level 1, 2 and 3 handoffs
Use this pattern when a ticket moves from a first-line desk to a specialist group and then to a third-line team, and the customer SLA must stay fixed while each internal team is measured on its own handoff time. Without per-level OLAs, the clock often stays with whoever opened the ticket, so a service desk leader cannot tell whether a delay sat with the service desk, the application team or the infrastructure team. The GLPI 12.0.0 release notes list group-managed OLAs as a capability, which is the starting point for attaching internal targets to the groups that actually hold the ticket.
The customer SLA remains the commitment you report against to the requester and their business. OLAs are internal targets that measure how long each group takes to acknowledge and resolve its share, so a level 2 breach should not change the customer's due date or priority. Plan the mapping before the build: which group owns each level, which status pauses the customer clock while work sits with an internal team, and whether a reassignment restarts an OLA. Confirm each of these in your own GLPI 12 instance by walking a test ticket through every handoff, because the sources used for this page do not describe how several OLA clocks interact on one ticket.
Reporting needs the same check. After the handoff test, compare the ticket statistics and OLA compliance figures for each group against the timestamps in the ticket history. If the reports disagree with the test ticket, treat the reporting as unproven and fix group assignments or business rule order before go-live. Ask your partner or GLPI contact to confirm the exact GLPI 12 settings for group-managed OLAs, including how each level appears in reports, and record the answers with the test results so the design can be reviewed later.
Choosing a handoff model for level 1, 2 and 3
This model keeps a single ticket for the whole request and attaches an internal target for each support group that touches it. The ticket stays the single record of work, while each level is measured against its own time target. Confirm in your GLPI 12 build how several OLAs attach to one ticket and how they are selected as the ticket changes hands.
- Clock ownership: The group holding the ticket carries its own OLA clock, so the level 2 target only runs while level 2 owns the work.
- Customer view: The requester sees one ticket and one status, and the customer SLA remains the only commitment visible on the request.
- Reporting: Statistics can be split by OLA, but a ticket that passes through several groups needs a clear rule for which group receives each interval.
- Operational load: Fewer objects to maintain, but routing and reassignment rules must set the correct OLA at every handoff.
Check how the pending status interacts with each OLA, because a pause set by one level can affect the reported figures for the others.
The GLPI 12.0.0 release notes list group-managed OLAs as a feature, so targets can be tied to the group that does the work rather than configured ticket by ticket. This matches teams whose levels are stable groups with their own service commitments. Because the exact behavior of assignment, inheritance and reporting depends on your configuration, confirm it against the GLPI 12.0.0 release and a test instance before you design around it.
- Clock ownership: The target should follow the group that owns the work, so confirm when the clock starts and stops as a ticket moves between groups.
- Customer view: The customer SLA is unaffected, and level handoffs stay internal unless notifications expose them to the requester.
- Reporting: Group-level reporting is the natural fit, but confirm whether historical tickets are re-evaluated after a group or target changes.
- Migration: Existing per-ticket OLA setups may need redesign, so plan a conversion and test it with representative tickets.
Ask for a worked example of a ticket that moves from level 1 to level 2 and then level 3, and check each clock value against the expected result.
In this model, level 3 work opens as its own ticket linked to the parent request. The child ticket has its own SLA or OLA, history and reporting, which suits engineering or vendor work with a different lifecycle from the front line. The parent keeps the customer commitment, so the two tickets must stay consistent without relying on memory.
- Clock ownership: The child ticket owns its own clock, while the customer SLA keeps running on the parent.
- Customer view: The requester sees the parent ticket, so the child's progress has to be reflected on the parent through notes, status changes or rules.
- Reporting: Each team gets clean figures, but cross-level totals require joining parent and child through the link.
- Divergence risk: Parent and child can drift apart, so define who may close each one and what closing the child should do to the parent.
Confirm which link type fits your process and whether closing the child can update the parent in your version.
No single model fits every service desk. The right choice depends on how often work moves between levels, whether level 3 work is internal engineering or external vendor work, and who needs to see which figures. Treat the three models as options to test against real ticket flows, not as settled answers.
- Workflow mapping: Document how often tickets move between levels, how many handoffs occur on a typical request and which groups own each step.
- Customer commitment: Confirm in each model where the customer SLA is evaluated, and make sure it is measured on the request the customer sees.
- Reporting needs: List the reports that leadership and each level require before choosing, so the model produces those figures directly.
- Pilot testing: Run sample tickets through the chosen model, including reopened tickets, pending periods and tickets that skip a level.
Record the decision and the test results before you apply the rules to the wider queue, so later changes can be compared against a known baseline.
Configuration options and when each fits
This table compares the main configuration choices for multi-level OLAs on one GLPI 12 ticket, with the situations where each fits and what it costs in maintenance. Read each row as a decision to confirm in your own instance before the first level 2 or level 3 handoff goes live.
| Configuration choice | What it controls | When it fits | Trade-off to confirm |
|---|---|---|---|
| OLA per support level | One OLA object for level 1, one for level 2 and one for level 3, each with its own targets | Separate teams own separate response commitments and each needs its own clock | More objects to keep in step with the customer SLA and more compliance views to read |
| Calendar assignment per OLA | The working hours that count toward each OLA's time to own and time to resolve | A level 3 team works on different hours than the service desk | Calendars must match real staffing, or breaches appear that no one can act on |
| Time to own (TTO) target | How long a ticket may wait before a group takes ownership | Handoffs need a clear point where the receiving group is accountable | Short targets on second-line groups can create breaches while tickets sit in a queue |
| Time to resolve (TTR) target | How long a group has to resolve its part of the ticket | Each level's resolution window differs from the customer SLA | Internal windows that sum to more than the customer SLA hide the real risk |
| Group assignment on the OLA | Which group's clock starts when a ticket is handed to that group | Teams are organized by function, such as network or application support | Confirm group membership and entity visibility so the right clock starts on each handoff |
| Escalation trigger on OLA dates | Whether a reassignment or notification fires before or after an OLA deadline | Breaches must reach a manager or the next level before the customer is affected | Triggers that ignore ticket activity may fire on tickets already being worked |
| Pending status handling | Whether waiting on the customer or another team pauses the OLA clock | Second-line work often waits on a third party or a requester reply | Pausing too freely can hide delays, so confirm which statuses stop each clock |
| Customer SLA left unchanged | The external commitment stays on the ticket while OLAs run alongside it | The customer contract does not change when internal teams split work | Reporting must show both the SLA and each OLA, or the internal view and the external view will disagree |
Setting up the OLA chain in GLPI 12
This sequence turns a single customer SLA into a chain of level 1, level 2 and level 3 OLAs on one ticket, so each team's time is measured separately while the customer-facing commitment stays the same.
Define groups for each support level
Create one GLPI group per support level, such as a level 1 service desk group, a level 2 application group and a level 3 infrastructure group. Assign members to each group and confirm that the groups are the ones that will receive assignments on tickets, since OLAs are attached to groups and the timers depend on them. Confirm with the service desk lead which teams own each handoff and whether any group is shared across entities. Done when every level has a named group with at least one active member and a documented owner.
Create the OLA calendars and targets
Define the working calendar each OLA uses, then create one OLA per level with its time to own and time to resolve targets. Ask the service desk lead to confirm these targets against the internal support agreements for each team, because the values must come from those agreements rather than from defaults. Keep the customer SLA as a separate object that is not edited in this step. Done when each OLA lists its calendar, its group and its targets, and the customer SLA is unchanged.
Attach OLAs to the ticket through rules or templates
Choose how the OLA for the first level is applied: through a ticket template for the request type, or through a business rule that sets the OLA when the ticket reaches a given group. Set the rule criteria so that the level 2 and level 3 OLAs are attached when the ticket is reassigned to those groups, and check the rule order so that no later rule overwrites the customer SLA. Done when a test ticket shows the customer SLA and the level 1 OLA together, and the other OLAs remain empty until their groups take the ticket.
Test a ticket through every handoff
Create a test ticket in a non-production entity and move it through each group in order: level 1 to level 2, then level 2 to level 3, and back to the requester after resolution. At each handoff, check that the correct OLA starts or stops, that the pending status pauses the clock where it should, and that the customer SLA still shows the original deadline. Record the timestamps for each step. Done when the recorded timeline matches the expected handoff sequence and no OLA starts before its group owns the ticket.
Check per-group statistics and compliance
Use the ticket statistics and the OLA compliance views to confirm that each group's time is reported separately and that the customer SLA is reported on the whole ticket. Compare the test timeline with the figures shown, and check that the report filters by group so each level can be reviewed on its own. Confirm the report definitions with the operations team before they are used in reviews. Done when each group shows its own time to own and time to resolve figures that match the test timeline.
Confirm the GLPI 12 behavior before production
Check the GLPI 12 release notes and your own test instance for group-managed OLA behavior, since the release notes list group-managed OLAs as a 12.0.0 change. Ask your GLPI administrator to verify that the version you run supports the chosen attachment method and that upgrades do not reset the OLA configuration. Record the confirmed behavior in the runbook. Done when the administrator signs off the test results on the exact GLPI version planned for production.
Access and audit risks when several teams share one ticket
Multi-level support puts one ticket in front of several teams, so access and audit controls decide who can read it and who can change the clock on it. The cards cover visibility by entity and profile, how level staff sign in, the admin actions that change OLAs, and the record left behind.
Scope level 2 and 3 by entity and profile
Level 2 and level 3 staff often belong to different groups or entities than the first-line desk. Give each level a profile whose rights match the tickets it handles, and limit visibility to the entities that own those tickets. Before go-live, sign in as a level 2 account and open a ticket from another entity to confirm it stays hidden. Confirm exactly which rights your version grants for viewing and editing OLA fields.
Control where level staff accounts come from
GLPI tries authentication sources in a fixed order: the internal database, then LDAP, then IMAP, then external methods such as REMOTE_USER. An engineer who exists in the internal database can keep signing in after the directory account is disabled. Decide which source is authoritative for each level, and test that a disabled directory account can no longer sign in.
Step-up authentication for admin actions
GLPI 12.0.0 adds step-up authentication for certain administrative actions, so a session that is already signed in must confirm identity again before those changes apply. For multi-level support, the sensitive edits are changes to SLA and OLA definitions, calendars and business rules, since one wrong target can shift breach reporting for every level. Confirm which actions the release covers in your version and document the list for your admins.
Review and revoke active sessions
GLPI 12.0.0 includes a view of active user sessions with the ability to revoke them. Use it when a level 2 or 3 engineer changes teams, leaves, or reports a lost device. Shared team logins make this harder to read, because one session can represent several people. Ask level staff to use named accounts and set a routine check of who is signed in to profiles that can edit OLAs.
Restrict who edits OLA targets
GLPI 12.0.0 lists group-managed OLAs, which lets ownership of an OLA sit with a group rather than a single administrator. Decide who may change OLA targets, calendars and the groups attached to each level. Editing a level 2 target after breaches have already been reported is the highest-risk change, so require a named approver before it is saved. Confirm how group ownership interacts with entity scope in your version before you assign it.
Keep an audit trail of OLA changes
Each OLA change should show who changed what, and when, so a disputed breach report can be explained later. Confirm whether your GLPI version records history for SLA and OLA objects, how long those records are kept, and whether they can be exported. Test one change end to end and check that the record appears before you rely on it for reporting on each level.
Reporting on each level without distorting the customer SLA
The customer SLA is measured on the ticket as a whole, so the reports that matter for each level must read the per-group OLA results beside it rather than replace it. In practice, per-group time to own and per-group time to resolve show how long a ticket sat with level 1, level 2 or level 3 before the next group took it, and how long each group needed to reach a solution. Confirm in your GLPI 12 version where these values appear in ticket statistics and whether they are filtered by group, by OLA or by both, because report layouts have changed between releases and the labels you see may differ from the ones used in this guide.
Separating internal waiting from customer waiting is the step most teams get wrong. A ticket moved to pending for a user reply should pause the customer SLA clock, but it should not be counted as a missed level 2 target, and an internal wait for a level 3 engineer should not be charged to the customer. Check how your OLA calendars and pending statuses interact before you publish any figure, and run a sample of tickets by hand to confirm that the time each group is credited with matches what happened in the ticket history. Record the reason for each pending status in a consistent way so the split can be audited later.
Build the review as a recurring meeting with a fixed set of views: the customer SLA compliance rate, the per-group OLA compliance rate, the number of handoffs per ticket, and the tickets that breached an OLA while still meeting the customer SLA. Save these as stored searches or dashboards owned by the service desk lead, and agree who reviews each one and what action follows a breach. Ask the vendor or your GLPI integrator to confirm which of these views can be saved and shared in your version, so the review does not depend on one person's manual exports.
What to confirm in your GLPI 12 environment before committing
A multi-level model depends on how your GLPI 12 instance behaves, not only on how it is designed. The checks below cover the behaviors that most often change the design once a build is underway, and each one should be confirmed in your own environment before the scope is agreed in writing.
Group-managed OLA behavior
GLPI 12.0.0 lists group-managed OLAs among its changes, but the exact rules for how an OLA is assigned to a group, how it interacts with the ticket's group field, and what happens when a ticket moves between groups need to be confirmed on your instance. Build a test ticket that passes through level 1, level 2 and level 3, then check which OLA clocks start, pause and stop at each handoff. Record the result before designing the reporting model around it.
Plugin compatibility after upgrades
If your current helpdesk relies on plugins for escalation, approvals or reporting, confirm that each one has a release for the target GLPI version and that it behaves correctly after the upgrade. Since GLPI 11.0, plugins are suspended when a new version is detected and must be reactivated after major updates, so plan that reactivation as a test step. Ask the plugin maintainers for their supported version list in writing.
Calendar handling across time zones
OLA and SLA targets are measured against calendars, so a level 2 team in one time zone and a level 3 team in another can produce different deadlines for the same ticket. Confirm which calendar is attached to each OLA, how holidays are defined for each site, and whether the clock follows the calendar of the assigned group or the entity. Test a ticket opened near a time zone boundary and a ticket that crosses a public holiday.
Escalation plugin or custom reporting
Core escalation rules may not cover every handoff you need, such as keeping a visible history of which groups held a ticket or returning a solved ticket to the first-line group. Decide whether the built-in escalation levels and business rules are enough, or whether a plugin such as Escalade is required. Also confirm that the standard ticket statistics can report time per level, or whether custom reporting is needed and who will maintain it.
Database and web server prerequisites
The prerequisites for GLPI 11.0 and GLPI 12 differ in their PHP and database versions, and the GLPI README and installation docs do not always state the same minimums. Check the requirements for your target version in the current prerequisites page, then confirm that your MariaDB or MySQL and PHP builds meet them. Only MySQL and MariaDB are supported as databases.
Questions buyers ask before a multi-level GLPI setup
What drives the cost of a multi-level support setup in GLPI?
The cost follows the number of levels, groups, OLAs and business rules, plus how many existing processes must be mapped first. Each level needs its own OLA, calendar, escalation path and reporting view, and each rule that moves a ticket between levels needs testing against real ticket data. Ask any provider for a quote that lists these items separately, and check whether it covers configuration only or also training, documentation and handover. Most engagements are fixed-scope, so the written scope sets the price. No price is published here, and GLPI's own subscription pricing, which the GLPI Network subscriptions page lists, covers the software license and support tier rather than the configuration work.
How long does a multi-level GLPI setup take?
Duration depends mainly on how many support groups exist, how many handoffs must be modeled, and how complex the business rules are for routing and escalation. A setup with two levels and a few groups is far shorter than one with three levels, separate OLAs per group and rules that depend on category, entity and priority. Before agreeing a timeline, confirm whether the process map is already written, whether the groups exist in your directory, and how many test cases the team expects. No duration figure is supplied for this work, so ask the provider to tie the timeline to the written scope and its milestones.
What must our team provide before the work starts?
Your team needs to provide a process map showing how a ticket moves from level 1 to level 2 and level 3, including who decides each handoff. You also need the list of support groups with their members, the working-hours calendars each group follows, and the customer SLA targets that must stay unchanged. Confirm which categories and request types feed each level, and who owns the reporting questions the levels must answer. Missing calendars and undefined handoff rules are the most common causes of delay, so resolve them before configuration begins.
Can an internal team set up multiple OLAs in GLPI 12 without a partner?
Yes, a team with GLPI administration experience can build this internally, provided it has time to test rule order and ticket behavior. The harder parts are not the screens but the logic: keeping the customer SLA separate from internal OLAs, making sure pending status pauses the right clocks, and verifying that escalation fires only on untouched tickets. Internal teams often underestimate test effort and the reporting work for each level. Consider a partner if your team lacks time for a test cycle, or if the process needs review across several business units.
How does an upgrade to GLPI 12 affect our SLA and OLA configuration?
GLPI 12.0.0 was released on October 7, 2026, according to the GLPI releases page, and its release notes list group-managed OLAs among the changes. Group-managed OLAs can change how targets are assigned, so review your existing OLA setup before and after the upgrade rather than assuming it carries over unchanged. Back up the database, files and the config directory including glpi.key and glpicrypt.key, as the GLPI update documentation requires. Also confirm that plugins used for escalation or routing are compatible with the target version, since GLPI suspends plugins after a new version is detected and they must be reactivated.
Which parts of the setup create the most risk after go-live?
The main risks are rules that reassign tickets in unexpected ways, OLA targets that do not match the working calendar, and reports that count the same time at two levels. Escalation rules that fire on tickets already being handled can also create noise and mistrust in the process. Plan a period of monitoring after go-live, review the ticket statistics for each level, and agree who owns rule changes. Ask any provider how they test rule order and what evidence they hand over at the end of the engagement.
Does the project cover ongoing support after handover?
The initial configuration is delivered under a written scope with defined deliverables. Ongoing support, upgrades and continuous testing are available as retainers, so you can decide whether to keep support in-house or extend it after the project. Ask what documentation is handed over, how rule changes are recorded, and who is responsible for the GLPI platform itself, including backups and version upgrades. Clarify these points in the written scope before work begins.
Planning this on GLPI 11 and 12 without rework
Settle the GLPI version before you build the level model, because the design depends on OLA behavior that is changing in the 12 line. GLPI 12.0.0 was released on October 7, 2026, and its release notes list group-managed OLAs among the changes. This matters for multi-level support: if each level's OLA is tied to a support group, group membership may drive which target applies at each handoff, instead of a manual setting on every ticket. Confirm in the 12.0.0 release notes how group-managed OLAs start and pause their targets, then test your planned level 1, level 2 and level 3 handoffs on a non-production instance. The GLPI 11 line began with 11.0.0 on October 1, 2025, and 11.0.11 is listed on October 1, 2026. If 12 is not ready for your organization, the 11 line is the fallback, but the group-based design would then need manual steps or business rules, and those need to be re-verified.
Upgrades in either line follow the same update procedure, and the backup set is where teams most often leave gaps. Before you replace the application files and run php bin/console db:update, back up the database, the files and the config directory, including glpi.key and glpicrypt.key. The OLA calendars, level groups, SLA and escalation definitions live in the database, while the keys sit with the configuration, so a backup missing either part gives you a restore you cannot rely on. Restore the full set to a separate copy and check that one open ticket at each level still shows the correct OLA, calendar and clock state. The step-by-step requirements are in the GLPI installation docs: Update guide.
Plugins are the second rework risk. Since GLPI 11.0, plugins are suspended once a new version is detected and must be reactivated after major updates. If any handoff in your model relies on a plugin, such as a group escalation extension, that handoff stops working until the plugin is reactivated, and tickets may sit at the wrong level without anyone noticing. Make reactivation a checkpoint in the upgrade runbook: list each plugin the multi-level model uses, reactivate it, then create test tickets at each level and confirm assignment, OLA start and the level reports. Ask each plugin publisher to confirm support for the target version before you set the upgrade date.
How DeployOpen scopes and delivers multi-level GLPI support
DeployOpen treats multi-level support in GLPI 12 as a written design of handoffs, OLAs and reporting, built and checked in infrastructure you control. The customer SLA stays the contract you answer to, and each internal level gets its own measurable commitment.
How we scope
- Map level 1, level 2 and level 3 queues, groups and the categories that move between them
- Agree in writing which OLAs attach to each handoff and which single customer SLA the ticket keeps
- Engagements are fixed-scope, with deliverables and timelines agreed before work starts
- Ask for a quote built from this written scope, including ongoing retainer support if needed
How we build
- Configure OLAs with calendars, time-to-own and time-to-resolve targets per internal group
- Build routing and escalation rules so the customer SLA is never overwritten by internal targets
- Test each handoff with scripted tickets that cross levels, pending states and reopenings
- Set up reporting views per level and confirm they match ticket statistics on sample data
How we hand over
- Document the level model, rule order, OLA definitions and the reasoning behind each setting
- Walk your service desk leads and group owners through daily handling and reporting
- Record backup and configuration steps so the setup can be restored or moved
- Confirm acceptance criteria against the written scope before closing the engagement
How we support
- Plan upgrades to later GLPI releases, including checks of rules and OLAs after each update
- Review reporting and escalation behavior when teams, calendars or categories change
- Offer ongoing support, upgrades and testing as a retainer after handover
- Confirm with your team which GLPI version and plugins are in scope before support starts
