GLPI problem management implementation for teams that already run incidents
Problem management in GLPI gives a service desk a place to record the root cause behind repeated incidents, so that the same faults stop returning to the queue. Teams usually implement it once they already run incidents in GLPI, notice the same categories of ticket recurring, and need a record that analysts and change owners can act on. The work is the linking of incidents to problems, the routing of problems to the right specialists, and the analysis, cost and impact records that show why a fix is worth doing.
Problems are a separate workstream from ticket configuration. Ticket rules, SLAs and escalation are already set up for incidents, but problems have their own lifecycle and their own business rules engine, which shares the interface and mechanisms of ticket rules. Under that engine, a problem can be given a category, a priority, an assigned group such as N3 experts, and a status automatically, so the team has to decide which problem types should be routed and by what criteria before the first rule is written. Confirm the rule set against the GLPI 12 documentation on business rules for changes and problems and test it in a non-production instance, since rules that reassign problems to the wrong group create backlog that is hard to see.
Because the module touches incident data, asset links, change requests and group permissions, it is usually scoped as its own workstream with a named owner from the service desk and one from the platform team. Ask any partner to confirm in writing which incident fields, linked assets and user profiles the problem records will depend on, how existing incidents will be linked to new problems, and who approves a problem's move into a change. Those answers drive the effort more than the number of screens, and they should appear in the written scope before work starts.
What the GLPI problem module does according to its documentation
The GLPI problem module connects incident tickets to a root-cause record, then routes that record through its own business rules. The cards below cover the parts a team configures: linking, routing, analysis, and the cost and impact records kept against each problem. Confirm exact field names and menu locations in the GLPI version you run, because the documentation changes between releases.
Problem records and their purpose
A problem record groups related incidents under one underlying cause so that technicians investigate once rather than answering the same tickets repeatedly. It is the record that carries the root-cause work, workarounds and the eventual known-error status. Before rollout, decide who may open problems, whether problems come only from incident trends or also from technician observation, and how closure is confirmed against the incidents it covers.
Linking incidents to problems
Incidents are attached to a problem so that their status, requesters and history stay visible from the problem view. The link is the basis for reporting how many users a single cause affected and for notifying them when a workaround or fix is available. Test the link on a sample of real-world duplicates in a staging instance, and confirm which ticket types can be linked in your version.
Business rules for problems
Problems have their own business rules engine that shares the interface and mechanisms of ticket rules. These rules can set the category, priority, assigned group such as an N3 expert group, and status when a problem is created or updated. Map each rule to a documented routing decision, then test rule order, because the first matching condition determines the outcome in a rules engine of this type.
Analysis and cause records
The problem record holds the analysis that teams use to justify a fix, including the cause description, the workaround and the decision taken. Agree a template for these fields before go-live so that closed problems can be audited later. Confirm which analysis fields and content types your GLPI version provides, and whether they are required on closure.
Cost and impact records
Teams record the effort, affected items and business impact of a problem so that the cost of recurring faults is visible to managers who fund the fix. Decide early whether cost is entered as time, money or both, and who maintains the figures. Confirm in your GLPI version which cost fields are available on problems and how they are reported.
Known errors and workarounds
A known error records a problem whose cause is understood even though no permanent fix is in place, so the service desk can apply a documented workaround. Keep the workaround text in a form technicians can find from an incident, and define who approves it. Confirm how your GLPI version exposes the known-error status and whether it links to the knowledge base.
Which problem routing model fits your service desk
A named problem manager reviews every new problem, decides its category, priority, owning group and status, and assigns it. This model suits service desks with a small number of recurring incidents, a stable set of support groups and a problem manager who already reads the incident queue daily. Its strength is judgment: a person can spot that two unrelated-looking incidents share a root cause. Its weakness is that routing stops when that person is absent or overloaded.
- Clear ownership: one role decides every routing choice, which keeps the record easy to explain.
- Capacity limit: triage time grows with incident volume, so confirm how many new problems a week one person can review.
- Coverage gaps: define a deputy for leave and out-of-hours periods.
- Inconsistent categories: without written criteria, two managers may classify the same problem differently.
- Manual status changes: the team must keep statuses and assigned groups current by hand.
Before choosing this model, confirm with your team how many problems are opened each month and whether the problem manager role has time for daily triage.
GLPI's business rules engine for problems and changes shares the interface and mechanisms of ticket rules. It can set categories, priority, assigned groups such as an N3 expert group, and status automatically when a problem matches defined criteria. This model fits environments where categories and asset ownership are well maintained and where routing follows fixed patterns, such as a platform or application group owning all problems on a given asset type. Its risk is silent misrouting when criteria are too broad or when source data is incomplete.
- Predictable routing: the same criteria produce the same assignment every time.
- Governance of rules: someone must own the rule set, review changes and retire rules that no longer match the organization.
- Data dependence: rules that match on category or asset need those fields filled in correctly.
- Rule order and overlap: confirm how multiple matching rules are evaluated and which action wins.
- Testing before go-live: replay representative problems through the rules and check the resulting groups and statuses.
In the GLPI 12 business rules for changes and problems documentation, confirm the criteria available for problems, the actions each rule can take, the evaluation order, and whether rules run on creation only or on updates too.
In the hybrid model, business rules set a default category, priority and owning group when a problem is created, and a problem manager reviews the result and overrides it when the context requires. This is often the most practical choice for mid-sized service desks: routine problems move without waiting, while unusual or high-impact problems still receive human judgment. It requires agreement on which fields rules may set and which fields only a manager may change.
- Defaults, not decisions: rules propose the initial routing, and the manager keeps the right to override it.
- Override record: decide how manual changes are documented so the reason for each override is visible later.
- Review cadence: schedule a regular review of overridden problems to find rules that need adjusting.
- Permissions: confirm which profiles can change rule-set fields on a problem after it is created.
- Escalation path: define what happens when a rule assigns a group that cannot take the work.
When scoping a hybrid model, ask for a worked list of the fields rules may set and the roles allowed to override them, and confirm the override behavior against your own GLPI 12 test instance.
Configuration decisions for problems, incidents and ownership
This table compares the design choices a team makes before configuring GLPI problem management, with the option, when it fits and the trade-off for each. Read it as a checklist to settle with process owners before anyone edits rules or templates, since most later rework traces back to one of these choices.
| Decision | Option | When it fits | Trade-off |
|---|---|---|---|
| Which incident categories open a problem | Only recurring incidents in named categories, raised by a technician | Teams with a mature incident record and clear recurrence signals | Fewer problems, but recurring faults in unlisted categories can go unnoticed |
| Which incident categories open a problem | Broad categories raised from any incident marked as major | Early-stage programs that want wide coverage and will triage later | Queue volume grows fast and analysts may stop reading each problem |
| Links between problems and incidents | One problem linked to many incidents | Recurring faults that share one root cause across users or sites | Incident counts roll up cleanly, but unrelated faults can be merged by mistake |
| Links between problems and incidents | One incident linked to one problem at a time | Teams that want a strict chain of evidence per incident | Harder to show that one incident contributed to several causes |
| Ownership of the problem queue | A central problem manager group that assigns analysts | Organizations with one process owner and a small set of specialist groups | The manager becomes a bottleneck unless capacity is planned |
| Ownership of the problem queue | Each support group owns problems for its own services | Large IT estates with strong service ownership | Cross-service problems can stall between groups without an escalation rule |
| Groups assigned by business rule | Assigned group set by category, asset type or entity, such as an N3 expert group | Stable service catalog and known specialist teams | Rules must be reviewed when groups or categories change, or problems route to empty queues |
| Groups assigned by business rule | Manual assignment after triage | Small teams or new programs still defining specialist areas | Slower routing and more reliance on the individual triager |
| Recording known errors | Known error status set on the problem, with workaround text kept in the problem record | Teams that want one record for analysis and the workaround | Workarounds must be kept current as analysis changes |
| Recording known errors | Known error knowledge base article linked from the problem | Organizations that publish workarounds to service desk staff or users | Requires an article owner and review cycle outside the problem queue |
How the problem management build runs in sequence
The sequence moves from agreed process rules to a tested, handed-over problem workflow in GLPI. Each step produces a record your team keeps, so the build ends with a configuration your own staff can operate and change.
Design the problem process and roles
Before any GLPI configuration, the team agrees what starts a problem, who owns the record, who approves a workaround or fix, and when a problem closes. DeployOpen runs these workshops with your service owner, problem manager and the group leads who will work problems day to day. The output is a short written process definition that names each role, the entry criteria and the closure rules. The step is done when the process owner signs off the document and no open question remains about who decides what.
Build the category and group model
Next, the team maps the problem categories, the support groups and the entities that will raise and receive problems, and aligns them with the incident categories already in use. This model decides how routing rules can target a problem, so mismatches here cause misrouting later. The output is a category and group table with an owner for each group and a list of any categories that will be retired or renamed. The step is complete when every incident category maps to at least one problem path and each group has a named lead.
Configure business rules for problems
The team then sets up the business rules engine for problems, which shares the interface and mechanisms of ticket rules. Rules can set category, priority, assigned groups such as N3 experts, and status automatically when a problem matches defined criteria. The team tests each rule against sample problems in a non-production instance and records the expected outcome beside it. The output is a documented rule set with criteria, actions and test results. The step is complete when each rule has a passing test case and the rule owner has accepted the expected routing.
Link incidents to problems
This step defines how incidents are associated with a problem record, who can perform the link, and what the affected user sees afterward. The team decides when a repeat incident triggers a problem review and whether linking happens manually, through a rule, or both. The output is a linking procedure for technicians and a verified set of test incidents linked to a test problem. The step is done when linked incidents show the expected status and a technician can trace from any incident to its problem and back.
Create analysis and cost record templates
Problem records need consistent content for root cause analysis, known error notes, workaround details and the cost and impact of the problem. The team builds templates that prompt for these fields so analysts record the same information across problems. The output is a set of template text and the field list that each analyst completes, reviewed against the process definition from the first step. The step is complete when a sample problem can be taken from raising to a documented analysis using only the templates.
Set up notifications for problem events
The team configures who is told when a problem is raised, assigned, changes status or receives a workaround, and which events go to managers rather than analysts. Notification settings are checked against the group model so that no owner is left out. The output is a notification matrix listing each event, its recipients and the channel used. The step is done when test problems produce the expected notifications and the matrix matches the agreed roles.
Run a pilot with live problem cases
The team selects a small set of real recurring incidents and runs them through the new workflow with the groups that will use it in production. Pilot results are compared against the process definition, and any routing, linking or template gaps are logged and fixed in a defined change cycle. The output is a pilot report listing issues found, the fixes applied and the open items accepted for later. The step is complete when the process owner confirms that the pilot cases were handled as designed.
Hand over the configuration and training
The final step transfers the configuration, documentation and operating procedures to your team. DeployOpen walks the owners through the rules, templates and notification matrix and confirms who can change each of them. Your team receives the configuration record, the test cases and a runbook for adding categories or rules. The step is done when your administrators can make a routine change to a rule and verify it with the existing test cases without vendor help. Ongoing support and changes after handover depend on the scope agreed in writing before the work starts.
What drives problem management effort and how to keep it down
This table lists the main factors that raise the effort of a GLPI problem management build and the lever that keeps each one under control. Read each row as a question to answer during scoping, because the same driver can be cheap in one organization and expensive in another. The main takeaway is that category design and historical data quality usually matter more than the GLPI configuration itself.
| Driver | Why it raises effort | Lever that reduces it |
|---|---|---|
| Number of incident categories | Each incident category may need a mapping to a problem category, a routing rule and a priority default. Many overlapping categories multiply rule combinations to test. | Consolidate categories before building problem rules, and map only the categories that produce recurring incidents. |
| Existing process maturity | If the team has no written problem criteria, every rule becomes a decision workshop. Unclear ownership of root cause analysis slows sign-off. | Agree written entry criteria, owners and review cadence first, then encode them as business rules. |
| Data quality in historical tickets | Inconsistent titles, missing categories and duplicate incidents make trend analysis and incident linking slow to validate and migrate. | Sample historical tickets early, define a minimum field set, and limit the backfill to a defined time window. |
| Number of approval or assignment groups | Each group that can own a problem needs its own assignment logic, notification targets and escalation path, all of which must be tested together. | Reduce the number of assignment groups to those that truly own root cause work, such as N3 experts, and use one routing pattern for the rest. |
| Integration with change management | Problems that produce changes need a clear link to change records, shared statuses and agreed rules for who raises the change. Mismatched status models cause rework. | Define the problem-to-change handoff and status meanings once, then build both sides against that agreed model. |
| Number of GLPI instances or entities | Separate entities or instances each need their own rules, visibility settings, profiles and reports. Cross-entity problems add access and reporting questions. | Keep one shared rule set where possible, and confirm with the vendor how business rules and visibility behave across your entity layout. |
| Volume of custom fields and analysis records | Extra fields for impact, cost, workaround and root cause add forms to design, reports to build and data to train users on. | Start with the analysis fields your reviews need, and add others only after a review cycle shows the gap. |
| Reporting and audit evidence requirements | If auditors or service owners need specific problem metrics or retained analysis, reports and retention rules must be designed and checked. | Ask the client's assessor or service owners for the exact evidence list before design, and build reports against that list. |
Migrating historical problems and known errors into GLPI
How do I map an existing problem log or known error list into GLPI problems?
Map each row of the legacy log to one GLPI problem, then carry its status, owner, priority and root cause text into the matching fields. Keep the original identifier in the title or a text field so auditors and staff can trace every record back to its source. Known errors usually become problems in a closed or workaround-available state, with the workaround written into the solution or analysis section. Agree this mapping in a short table before any import runs, because it decides which legacy columns have a home in GLPI and which must be kept as attached documents. Confirm the exact field list against your GLPI version, since problem fields differ between releases.
What should we clean up before importing old problem records?
Clean the source data before it touches GLPI, because the import will copy every duplicate, typo and stale status into a system people will rely on. Start by removing exact duplicates, merging near-duplicates that describe the same fault, and closing or archiving problems that have been resolved for years. Standardize owner names to the users or groups that exist in GLPI, and normalize priority and category labels to the values you will use going forward. Check that each remaining problem has an owner and a current status. Keep a copy of the untouched original spreadsheet or export so every cleanup decision can be reviewed later.
How do we link legacy incidents to migrated problems without creating duplicates?
Link legacy incidents to the migrated problem they belong to, and do not recreate the incidents as new tickets. Build a crosswalk file that pairs each legacy incident ID with its target problem ID in GLPI, then use it to create links after the problems exist. Where incidents were never tied to a root cause, match them on shared symptoms, affected assets and dates, and mark uncertain matches for review rather than guessing. Imported incidents that already exist as tickets should be linked, not imported a second time. Count incidents before and after the link step so you can show that nothing was dropped or doubled.
Which GLPI migration tools can load problem data from spreadsheets?
The migrating-to-GLPI content group covers the tools GLPI documents for loading spreadsheet and system data into a new instance, and that is the right next read for the loading method. Check which tool supports the object types you need, because a generic asset or ticket loader may not cover problem records and their links in the same run. Test the chosen tool on a copy of the database with a sample of rows, including the messy ones you found during cleanup. Record every rejected row and the reason, and do not force rows through with placeholder values.
Should historical known errors be imported with their original analysis and costs?
Import the analysis text and the root cause narrative, because they explain why a workaround exists and teams search for them. Cost and impact figures from old spreadsheets are harder to carry over: confirm whether the source numbers were actual, estimated or in a currency and period that still applies. If they cannot be verified, store them as attached documents or notes labeled as legacy, rather than as structured values that reports will total. Decide this per field before the import, so the financial reports built later are not mixing verified and unverified amounts.
How do we validate a migrated problem backlog before teams start using it?
Validate the backlog with counts and sampling. Compare the number of source rows to the number of imported problems, incidents linked and rows rejected, and explain every difference. Then pick a sample of problems across statuses and owners and check them against the original sources with the people who worked them. Confirm that known error workarounds appear where technicians will look for them and that owners can see and edit their records. Keep the validation results with the migration record, because reviewers will ask how you know the data is complete.
Can our own team do the problem record migration, or do we need a partner?
Your own team can do the migration if it has time to own the mapping, cleanup and validation, and if someone knows both the legacy data and GLPI's data model. The work is mostly judgment about which records to keep, merge and link, so the people who know the old process should be involved even if a partner handles the tooling. A partner is useful when the source data is large, spread across systems or heavily duplicated, or when the timeline is tight. DeployOpen works on fixed scopes agreed in writing, so ask for the mapping, cleanup rules and validation steps to be listed as deliverables in any quote.
How problem records connect to changes, assets, notifications and identity
A problem record is only useful if it sits in the same data as the incidents, changes, assets and groups around it. The cards below cover the links you need to design and the points where GLPI behavior depends on your version and configuration.
Linking problems to incidents
Each problem should point back to the tickets that revealed it, so recurring incidents roll up into one analysis record. Decide early who may link a ticket to a problem, whether the ticket is closed when the link is made, and how the technician sees the problem from the ticket. Test the link with a sample set of recurring incidents before you train the service desk on it.
Raising changes from problems
A problem usually ends in a fix that must go through change control, so the problem-to-change link matters for audit trails. Confirm in your version whether a change can be raised directly from a problem, which fields carry over, and whether the workflow stays tied to the originating problem after the change closes.
Impacted assets and CMDB items
Record the computers, network devices, applications and other items affected by a problem so that impact is visible from both sides. Check which asset types can be linked to problems in your build and whether linked items show in impact analysis. Custom asset types may need separate testing.
Group notifications and assignment
Notifications for problems go to the groups or users set on the record, so the group model drives who hears about a change in status. Map which groups own analysis, which receive updates and which only watch. Confirm the notification templates and recipients with a test problem in a non-production entity.
Identity and group membership
Assignment is only as accurate as the group data behind it. If users arrive through LDAP, an external directory or web server SSO, group membership from that source decides who sees and receives problem work. Confirm how your authentication method maps directory groups to GLPI groups and profiles before you build routing rules on top of them.
Business rules for problem routing
Problem business rules can set categories, priority, assigned groups such as N3 experts and status when a problem is created or updated. Review the rule order and conditions so that a rule does not overwrite a manual assignment. Confirm the available criteria and actions in your GLPI version before you write them.
How much effort GLPI problem management takes and what your team must provide
What drives the cost of a GLPI problem management implementation?
The cost follows the written scope, and the largest drivers are the number of problem categories, the number of teams that route and resolve problems, and how many business rules you need. Each rule that assigns a category, priority, group such as N3 experts or a status adds design and test work. Integration with existing change management, incident volumes you need to migrate or link, and the number of approval and review steps also add effort. Ask any provider to price these drivers separately so you can see which ones you can reduce.
How long does GLPI problem management setup usually take?
Duration depends mostly on how settled your problem process is before build starts. A team with defined ownership, a stable category list and clear escalation paths moves faster than one that must first agree on what a problem record is for. Other drivers include the number of business rules, how many sample incidents must be tested, and whether the work is paired with a GLPI upgrade or a change management build. Ask for a timeline tied to named milestones in the written scope, not a single overall figure.
What must our team provide before a GLPI problem management project starts?
Your team needs to supply the people and material that define how problems are handled. The main inputs are:
- Named process owners who can decide categories, priorities and closure criteria
- A current category list for incidents and the groups that resolve them
- Sample incidents, including recurring ones, so routing rules can be tested against real patterns
- Your existing escalation paths, including who the N3 experts are and how they are reached
- Access to a non-production GLPI instance for testing business rules
Missing owners or inconsistent categories are the most common causes of rework.
Can our own team build GLPI problem management without a partner?
Yes, a capable internal team can configure problem management in GLPI, since the business rules engine for problems uses the same interface and mechanisms as ticket rules. The work is most manageable when a team already administers GLPI and has someone who owns the ITIL process design. The harder parts are testing rules against realistic incident patterns, keeping the analysis, cost and impact records consistent, and documenting decisions for auditors. Estimate your own capacity honestly, and weigh it against the cost of delayed or inconsistent problem records.
What should a written quote for GLPI problem management include?
A written quote should follow from a written scope that lists the deliverables. Ask for the following to be stated explicitly:
- The problem categories, business rules and groups in scope, with a count
- The incident linking approach and any historical data to be migrated
- Who performs testing, and how many test cycles are included
- Documentation and training for process owners and technicians
- Which items are one-time work and which recur, such as rule reviews or support retainers
- Assumptions about your environment and the inputs you must provide
Any item missing from the quote is a cost you may meet later.
What recurring effort does GLPI problem management need after go-live?
After go-live, the recurring effort is mostly rule and process maintenance. Categories change as services change, groups are reorganized, and new recurring incident patterns call for new problem records or rule adjustments. GLPI itself also needs upgrades, and the GLPI 11 update procedure requires plugins to be reactivated after major updates, so plan time for regression checks on any custom rules. Ongoing support and upgrades can be arranged as a retainer, and that cost should be priced separately from the initial build.
Does GLPI problem management need a licensed GLPI Network subscription?
GLPI is distributed under the GNU General Public License version 3, so the core platform can be self-hosted without a subscription. Problem management is part of the core ticket and ITIL functionality. Paid GLPI Network subscriptions are a separate decision that covers managed hosting or vendor support levels, and their published prices are listed on the GLPI subscriptions page for reference. Confirm with the GLPI project which features you need, and check the license terms of any plugin you plan to use.
What you keep after a DeployOpen problem management build
The handover set is what makes a problem management build usable after the engagement ends. You keep the documented business rules for problems, the process diagrams showing how a problem moves from identification through analysis to a known error or closure, and the record templates your analysts fill in for root cause analysis, workarounds, cost and impact. You also keep a role matrix that names who can create problems, who owns analysis, which group such as N3 experts takes assignment, and who approves a workaround. Each item is written against your entity structure and your configured categories, so an operator can trace any rule back to the decision that produced it.
Test evidence and the operator runbook come last. The test evidence records the incidents you linked to a problem, the rule outcomes you checked (category, priority, assigned group and status), and the notifications you confirmed, so your own auditors or internal reviewers can see what was tested and what passed. The runbook covers routine tasks such as reviewing rule changes, handling a problem that was routed to the wrong group and adjusting templates. Confirm with us, in the written scope, exactly which artifacts are delivered as files, which are configuration exported from your instance, and which are demonstrated only during handover.
The work is fixed-scope: deliverables, timelines and the acceptance criteria for each artifact are agreed in writing before work starts, and the quote follows from that scope. Once the build closes, ongoing support, GLPI upgrades that touch problem rules, and periodic review of the rule set can be covered by a retainer, which is a separate written agreement. Ask for the retainer terms and the handover checklist in your proposal so you can compare them with running problem management in-house.
How DeployOpen scopes and delivers GLPI problem management
DeployOpen plans, implements, customizes, documents and supports self-hosted open-source platforms inside the client's own infrastructure, and GLPI problem management follows the same approach. We agree the scope in writing first, then build and hand over the problem workflow, business rules and records your team will run.
How we scope
- Map how incidents, known errors and problem records flow today across your service desk and technical groups.
- Define which problem categories, priorities and assigned groups the business rules engine must set automatically.
- Agree the analysis, cost and impact fields your teams keep, in a written fixed-scope document before work starts.
How we build
- Configure incident-to-problem linking and the problem templates that capture root cause and workaround details.
- Build business rules for problems in GLPI, testing each rule against representative tickets in a non-production instance.
- Verify notifications, approvals and status transitions with the groups that will use them before cutover.
How we hand over
- Document the configured rules, categories, statuses and assigned groups so administrators can maintain them.
- Walk through the problem lifecycle with service desk, N3 and change owners using your own sample records.
- Provide a handover pack covering configuration, test results and the open items your team must confirm.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after the initial handover.
- Review rule changes and GLPI version upgrades against your problem workflow before they reach production.
- Confirm with your team which support and retainer terms apply, since they are set out in the written scope.
