The "GLPI for the whole company" pitch is easy to make and easy to oversell. The honest answer is that GLPI is shaped for a specific kind of work — discrete, state-based requests with a start, a couple of transitions, and a close — and some non-IT work matches that shape perfectly while other non-IT work emphatically does not. Knowing which is which saves you from a rollout that takes three months to back out of.
The shape of a good GLPI use case
GLPI's model is: someone submits a request, it enters a queue, it moves through a small number of states (New, Assigned, In Progress, Solved, Closed), someone acts on it, maybe it needs an approval, then it's done. Everything GLPI is good at — the categories, SLAs, notifications, KB suggestions, reporting, auto-close — assumes this shape. If the work you want to model has that shape, GLPI will handle it with almost no adaptation, whether it's tagged "IT ticket" or not. If it doesn't, no amount of template customization will make it fit.
Where GLPI lands well outside IT
Four patterns we see working reliably in the installs we run:
- HR onboarding and offboarding requests. A new hire is a ticket with a checklist: account, laptop, badge, building access, payroll setup. HR submits once, tasks fan out to the responsible groups, everyone sees the same state. Far better than the spreadsheet that usually handles this.
- Facility maintenance and space requests. "Printer on floor 3 is jammed," "meeting room needs new chairs," "AC is dripping in the kitchen." Short-lived requests with a single assignee — exactly what the ticket model was built for.
- Fleet and non-IT asset tracking. GLPI's inventory isn't limited to computers. Vehicles, printers, projectors, company phones, tools — the same CMDB handles them, and the same tickets attach to them. Useful when you're already running GLPI for IT and don't want a second asset system.
- Vendor and contract renewals. Each renewal is a ticket with a date, an owner, an approval step, and a close. GLPI's notifications keep you from missing the window without setting up a dedicated contract lifecycle tool.
Where GLPI is the wrong shape
The use cases that keep coming up and keep failing: CRM (leads aren't discrete requests — they're long-lived records with ongoing activity), sales pipelines with custom stages, finance approval chains with five levels of sign-off and branching (business rules can't express this — see the workflow layer), complex project management with Gantt charts and dependencies, and anything with long-lived documents that need versioning. These are record-centric workflows, and GLPI is ticket-centric. Forcing them in produces a system that technically holds the data but makes it painful to find, update, and report on.
A simple test
Before trying to add a new non-IT process to GLPI, ask: can this work be described as "someone asks, it goes through a small number of states, someone closes it, and then it's done"? If yes, GLPI will carry it without much extra work. If the answer is "well, sort of, but the record keeps needing updates after it's closed, and there are reports that span many of them, and sometimes we reopen them for quarterly review," you want a different tool. Honesty at this step is cheaper than a migration six months later.
Where to start if you're adding a non-IT team
Pick the narrowest possible slice — not "everything HR does," but "onboarding requests" specifically. Configure the category, the form fields, the assignment group, and the SLA for just that slice. Run it for six weeks. If the team is using it voluntarily after six weeks, add the next slice. If they're still sending emails, stop and figure out why before expanding. The failure mode isn't GLPI — it's the assumption that an additional team will change how they work just because a tool was installed.