GLPI's knowledge base works fine when one team writes articles for one audience. It becomes a mess when three departments start dumping content into the same flat list. Network operations writes articles about switch configurations, the helpdesk writes password reset guides for end users, and security publishes incident response procedures that half the company should not see. Without structure, the KB turns into a search-and-pray exercise.
Category design
GLPI's KB uses a tree of categories, similar to ticket categories. The temptation is to create one category per team — "IT," "Network," "Security" — but that mirrors your org chart, not how people search. A better approach is to organize by audience and action.
A practical top-level structure:
- End-user guides — password resets, VPN setup, printer installation, software requests. These are the articles you expose in the self-service portal.
- Technician procedures — escalation workflows, diagnostic checklists, vendor contact details. Visible only to agents.
- Infrastructure — network diagrams, server configurations, firewall rules. Visible to specific teams.
- Policies and compliance — incident response plans, data handling procedures, audit checklists. Restricted by entity or profile.
Sub-categories within each level can follow your team structure if needed, but the top level should answer: "who is this article for and what are they trying to do?"
Entity visibility
In a multi-entity GLPI, every KB article belongs to an entity and can be set as recursive (visible to child entities) or not. This is the primary access control mechanism.
If your GLPI has entities for different business units — say "Headquarters," "Branch Office A," "Branch Office B" — you can write articles that are only visible within a specific entity. A branch-specific printer setup guide stays in that branch's entity. Company-wide policies go in the root entity with recursive visibility.
The mistake to avoid: putting everything in the root entity with recursive on. That works for small setups but defeats the purpose of entities once you have teams that should not see each other's internal documentation.
FAQ vs. internal articles
GLPI distinguishes between regular KB articles and FAQ items. The difference is visibility in the self-service portal: FAQ articles appear in the public-facing knowledge base that end users see when they log into GLPI. Regular articles are only visible to technicians in the back-end.
Use this distinction deliberately:
- Mark an article as FAQ when the target audience is end users — "How to connect to the VPN," "How to request a new laptop."
- Keep articles as regular KB entries when they contain internal procedures, vendor-specific details, or anything that would confuse rather than help an end user.
A common pattern is to write two versions of the same topic: a short FAQ article for end users ("How to reset your password — click Forgot Password on the login page, follow the email link") and a detailed technician article ("Password reset fails when AD replication is lagging — check the DC sync status before escalating").
Keeping content current
A KB with outdated articles is worse than no KB at all — agents stop trusting it and go back to asking colleagues on chat. GLPI does not have a built-in review cycle for KB articles, but you can simulate one.
Review date in the content — add a line at the bottom of every article: "Last verified: 2024-10." When an agent uses an article and confirms it is still accurate, they update the date. When they find it wrong, they flag it.
Ownership by category — assign each KB category to a team. That team is responsible for reviewing their articles quarterly. This works better than assigning individual article owners, because people leave and articles get orphaned.
Link articles to ticket templates — when a KB article is linked to a ticket category, agents see it every time they work on that type of ticket. If the article is wrong, they notice fast. Articles that are never linked to anything tend to rot silently.
The structure you choose on day one will either scale or collapse. Flat lists and team-based categories collapse. Audience-based categories with entity visibility and deliberate FAQ flagging scale to hundreds of articles across multiple teams.