An IT manager sends a plugin RFP to three vendors. All three quote. Six months later the plugin is delivered — and the original problem is still there. The reporting module the team wanted was only half the story; what they actually needed was a different category tree and three business rules. No one raised this during scoping because scoping had been framed as a build spec, not a diagnosis.
This happens often enough that we now run a plugin triage before any code gets quoted. It takes about a day, and roughly half the time it ends with "no plugin needed." The sections below are what that triage checks.
The cheapest solution you haven't tried
GLPI's built-in configuration tools cover more ground than most administrators realize. Work through them in order before reaching for code.
Business rules. Auto-assign tickets by requester group, title keyword, or source. Change priority or category on the fly. Add watchers, set due dates, update a custom field. A 400-user helpdesk that believes it needs an "SLA plugin" can usually get there with entity-level SLAs and three or four business rules — an afternoon's work, not a quarter's.
Custom fields via the Fields plugin. Community-maintained, covers most "we need to track X on every ticket" asks — dropdowns, text, dates, yes/no flags — on any item type.
Ticket templates. Control which fields are visible, mandatory, or pre-filled per category. If half your change tickets are missing a risk assessment, the answer is a template with risk as a mandatory field, not a new workflow.
Notification templates. Full HTML, variable substitution, per-event. If the ask is "we want a different email when a P1 incident is resolved," this is where it lives.
If the requirement fits one of these shapes, configuration wins. It survives upgrades with minimal effort and doesn't create a long-term maintenance dependency on a single developer.
When you actually do need a plugin
There are three shapes of problem where GLPI genuinely runs out of room and a plugin is the right answer.
New object types. Industry-specific things GLPI has no primitive for: medical device registries with regulatory fields, fleet objects with mileage and service intervals, facilities objects tied to floor plans. Legitimate plugin cases — you need new database tables, new forms, new reports.
Integration endpoints. Bidirectional sync with SAP, a proprietary HR system, a CMDB that isn't GLPI's own. GLPI has a REST API, but the glue — mapping, error handling, retry logic, scheduling — lives in a plugin.
Workflow engines beyond business rules. This is where most teams make the wrong call. Business rules handle single-step automation well. As soon as you need multi-step approval chains, conditional branching, task dependencies between actors — anything resembling "if the change is medium-risk route to the CAB, otherwise auto-approve" — you have outgrown them.
The mistake is commissioning a custom workflow plugin for this. We have watched several clients do it. Each took three to four months, each cost more than the original estimate, and none survived a GLPI major-version upgrade without another round of paid work. So we built Cascade: multi-step approvals, conditional branching, task chains. Because we maintain Cascade across GLPI versions, upgrade work sits with one team rather than with each client separately.
The general rule: if an existing plugin covers 80% of your workflow need, use it and negotiate the remaining 20% as customization — not as a new build.
The three costs nobody quotes for
Development hours are easy to estimate. The real costs are the ones that do not appear on the invoice.
1 · The spec pass. A usable plugin spec takes a week or two of someone's time — interviews with users, walkthrough of existing tickets, decisions about edge cases. If the vendor does not do this, you do. If no one does, the plugin gets built against a misread of the problem and has to be reworked after delivery.
2 · Major-version breakage. GLPI ships a major version roughly every two years. Internal API changes. Database schema evolves. Frontend rendering shifts. Any plugin that touches non-trivial internals needs maintenance work per release — typically 10 to 30% of the original build cost. If no one owns this cost, the plugin freezes on an old GLPI version, which means you either miss security patches or run parallel instances.
3 · Knowledge transfer. A plugin commissioned from a single developer dies when that developer moves on. The repository sits untouched until something breaks. Six months later no one on the current team can read the code — and any new vendor will quote "rewrite" because it is cheaper than archaeology. A plugin from an active codebase (community or commercial) avoids this entirely.
How to evaluate a plugin vendor
Whether the work goes to us, to another shop, or to the community, these questions separate vendors who understand the maintenance model from those who only build-and-run.
- Do you still maintain plugins you built three years ago? Can you show one that has been updated for the current GLPI release?
- Do I get the repository, or is the code hosted somewhere I lose access to if we stop working with you?
- If we already have a plugin from a prior vendor, can you patch it — or does your process require rebuilding from scratch?
- What is your track record through the last two GLPI major upgrades? How many of your plugins needed rework, and how long did it take?
Reasonable answers to these questions cost more per hour than vendors who cannot answer them. That is the point.
The decision in practice
The best GLPI deployments we see run three to five plugins, all actively maintained, most from the community. The worst run fifteen, half of them broken or locked to a GLPI version from two years ago. The question is not "can we build this?" — most things can be built. It is "will this still work when GLPI 12 ships?"
Start with configuration. Use existing plugins where they cover the need. Commission new development only for the shapes that genuinely require it, and only from vendors who will still be maintaining it in three years.