The self-service portal in GLPI isn't a "nice front end for the helpdesk" — it's the gateway through which 60–80% of requests should resolve without a technician touching them. To make that work it needs to be configured so a user can find what they need in under 30 seconds. That means a categorised service catalogue, forms with the right fields, linked KB articles, and clear separation between the end-user view and the technician view.
End-user view vs. technician view
GLPI ships two distinct UIs: the Self-Service interface (URL /front/helpdesk.public.php) and the Standard interface for technicians. The choice is set on the user's profile in Setup → Authentication → Profiles → Default profile. The end user sees:
- A Create ticket button that opens a categorised form.
- The list of their open and closed tickets.
- Knowledge base search.
- Active notifications (FAQ, system outage, scheduled maintenance).
The technician has full access to inventory, projects, problems, validations and other modules. An end user must never see the Assets → Computers or Tools → Reports tabs — that's noise and confusion. The profile configuration is both a security boundary and a UX boundary.
Service catalogue via categories and templates
GLPI doesn't have a native "service catalogue" object — it's modelled through the ITIL Categories tree (under Setup → Dropdowns → ITIL categories). Define a hierarchy that matches how users think, not how IT teams are organised:
Hardware
├── Laptop / PC
│ ├── Laptop not working
│ ├── Slow computer
│ └── New laptop request (with approval)
├── Printers
│ ├── Printer not printing
│ └── Toner / consumables
└── Peripherals
├── Monitor / keyboard / mouse
└── Headset (for Teams calls)
Software
├── Office / M365
│ ├── Outlook issues
│ └── Teams issues
├── System access
│ ├── Password reset (with self-service link)
│ └── New access request (with approval)
└── Software purchase (with approval)Each category can have a ticket template (under Tools → Ticket templates) with predefined fields: which technician is assigned, which priority, which SLA, which custom fields. Picking a category then auto-tunes the form.
Advanced forms via Formcreator
Native GLPI forms are simple — name, description, attachments. For service requests with conditional behaviour (for example "Request access to system X" → if X is a critical system, show a "Purpose and access duration" field and require manager approval) you reach for the Formcreator plugin.
Formcreator setup, step by step:
- In Administration → Forms → Add create a form, give it a name and description.
- Add sections (logical groups of fields) and fields (text, textarea, checkbox, dropdown, file upload, date, hidden).
- For conditional fields, in the Conditions tab set reverse logic — the field appears when another field has a specific value.
- In the Targets tab, define what the form creates — a Ticket with a preset category, or a Change for change requests.
- In Properties, decide whether the form requires validation (approval by a manager or service owner).
Formcreator exists in two main flavours — Glpi-Project/formcreator (the original, GLPI 9 – 10) and in GLPI 11 some of the functionality moved into a native Service catalog module.
Linking KB articles to forms
The best ticket is the one that never gets opened — because the user found the answer themselves. In GLPI you can engineer for that:
- In the Password reset FAQ category, publish a KB article called How to reset your password via M365 self-service.
- On the Formcreator form for Password reset, set the FAQ link — opening the form will surface the suggestion "You may be able to fix this yourself: How to reset your password".
- In reporting, log how many times the form was opened vs. how many times it was actually submitted — that's the real deflection rate, and the only honest signal that your KB articles are working.
A good KB article is short, screenshot-driven, and gives the user precise steps. A generic "contact support" answer doesn't belong in a KB — it belongs only as the fallback at the end of the form.
Practical rollout
A staged rollout in a mid-sized company typically looks like this:
- Week 1 — define the top 10 categories based on what's coming in by email today (analyse the last 200 tickets).
- Weeks 2 – 3 — configure categories, ticket templates, and end-user profiles.
- Week 4 — pilot with a single department (for example finance). Collect feedback, tune the forms.
- Weeks 5 – 6 — KB articles for the top five most frequent requests. Link them into the forms.
- Week 7 — company-wide rollout, comms, and training via an internally-shot 3-minute video tutorial.
The self-service portal is not "install it and turn off email". It's an iterative process, where categories and forms keep evolving based on what users actually submit. After six months, a well-maintained portal stands a chance of delivering what sales decks usually promise — the IT team can focus on genuinely complex cases, not the sixth password reset for the same colleague that week.