Knowledge that lives in one technician's head dies when they leave - but a badly configured knowledge base is worse: it looks like documentation and returns zero results. Maintaining GLPI estates for clients, the two failures we see most are articles nobody finds (a configuration problem) and articles nobody writes (an engagement problem). This guide tackles both, with the queries and tweaks we actually run in the field.
Design the taxonomy before the first article
GLPI's knowledge base is native (the glpi_knowbaseitems table) and already ships with categories, FAQ, full-text search, visibility control, revision history and ticket linking. The common mistake is to start with articles and let the category tree grow on its own: six months later you have twelve levels and nobody finds anything. Lock the structure first:
- Two levels of category at most. If you need a third, it is probably a tag, not a category.
- Actionable titles: "How to reset an AD password" beats "Active Directory". Users search by action, not by system.
- Four families cover 90% of cases: How-to (tutorials), Troubleshooting (known errors), Policies (rules) and FAQ (public).
- An article can live in several categories in GLPI 10/11 (the glpi_knowbaseitems_knowbaseitemcategories table). Use it sparingly: too many categories is the same as none.
The mistake that makes articles "vanish": visibility
In sustaining work, the number 1 failure we find is not a missing article - it is a published article nobody can see. The technician writes it, saves it, marks it published and assumes it is live. But GLPI visibility works by explicit target: if nobody added a profile, group, entity or user on the recipients tab, the article is visible only to its author - and GLPI gives no warning at all. We have audited bases with hundreds of articles where dozens sat in that limbo. That is why, during a sustaining onboarding, the first thing we run is the orphan-visibility query, before discussing taxonomy or engagement:
-- NON-FAQ articles with no visibility target at all:
-- they exist, count in the total and are invisible to everyone but the author.
SELECT k.id, k.name
FROM glpi_knowbaseitems k
LEFT JOIN glpi_knowbaseitems_profiles p ON p.knowbaseitems_id = k.id
LEFT JOIN glpi_knowbaseitems_users u ON u.knowbaseitems_id = k.id
LEFT JOIN glpi_groups_knowbaseitems g ON g.knowbaseitems_id = k.id
LEFT JOIN glpi_entities_knowbaseitems e ON e.knowbaseitems_id = k.id
WHERE k.is_faq = 0
AND p.knowbaseitems_id IS NULL
AND u.knowbaseitems_id IS NULL
AND g.knowbaseitems_id IS NULL
AND e.knowbaseitems_id IS NULL;One detail that only bites whoever writes this query: the four visibility table names are not symmetric. Users and profiles use glpi_knowbaseitems_users and glpi_knowbaseitems_profiles, but groups and entities flip to glpi_groups_knowbaseitems and glpi_entities_knowbaseitems. Swap the order and you spend hours debugging a LEFT JOIN that never matches.
Why "AD", "VM" and "PC" return nothing in search
The KB search is not a LIKE: GLPI builds a MATCH(name, answer) AGAINST(... IN BOOLEAN MODE) over the table's FULLTEXT index. On MariaDB/MySQL with InnoDB (the default in GLPI 10 and 11), innodb_ft_min_token_size sets the minimum indexed word length, and the default is 3. The consequence: two-letter acronyms - "AD", "VM", "PC", "IT", "DB" - never enter the index, and searching for them returns empty even with dozens of articles that mention them. This is the number 1 reason behind "the KB search is useless" that we hear from clients. Diagnosis:
SHOW VARIABLES LIKE 'innodb_ft_min_token_size';Lower the limit to 2 in the MariaDB config file and restart the service:
# /etc/mysql/mariadb.conf.d/50-server.cnf (MariaDB)
[mysqld]
innodb_ft_min_token_size = 2The part almost everyone forgets: changing the variable does not reindex existing articles. The token size is baked into the index at creation, so you have to rebuild it. The most direct way is to force a table rebuild:
-- Restart MariaDB and rebuild the FULLTEXT index
-- (the new token size only applies after the index is recreated):
ALTER TABLE glpi_knowbaseitems ENGINE=InnoDB;The common error is to lower the token to 2, restart and declare victory - the variable changes, but the old index keeps ignoring the acronyms until it is rebuilt. On legacy MyISAM installs, the equivalent parameter is ft_min_word_len.
Validity window: the article that only shows up tomorrow
Another silent trap is the article's begin_date and end_date fields. GLPI filters out of search any article whose begin_date is in the future or whose end_date has already passed. It is handy to publish a procedure only from a given date - but it is also the classic cause of "I created the article and it does not appear": someone filled in a start date by accident. If a fresh article does not surface in search and visibility is correct, check the validity window before anything else.
Public FAQ for self-service
For an article to show up on the end-user portal, mark it as FAQ (the is_faq field) and set entity visibility with the recursive option on, to propagate to sub-entities. If you want the FAQ reachable without login, enable the FAQ for anonymous users in GLPI's Assistance settings. The matrix we use to decide where each article lives:
| Goal | is_faq | Visibility target | Where it appears |
|---|---|---|---|
| Public FAQ (self-service) | 1 | Entity + recursive | User portal; without login if the anonymous FAQ is enabled |
| Internal technical base | 0 | Profile (e.g. Technician) | Knowledge base tab, only profiles with the right |
| Per-client procedure | 0 | Specific entity | Only technicians of that entity |
| Draft / under review | 0 | None (author only) | Invisible - use on purpose, never by forgetting |
Note the last row: "no target" is a valid state for a draft, but it must be a conscious choice, never the result of forgetting to fill in visibility.
Engagement: the KPI that works (and the one that does not)
The "X articles per technician per month" KPI that ITSM literature loves produces junk: articles written to hit a number that nobody reads. What works in practice is tying creation to work that already happens - closing tickets in recurring categories. Instead of demanding volume, spot the repetitive and turn it into an article. This query lists the subjects that repeated the most over the last 90 days, the highest-return candidates:
-- Ticket subjects repeated over the last 90 days:
-- the highest-return candidates to become KB articles.
SELECT t.name AS subject, COUNT(*) AS total
FROM glpi_tickets t
WHERE t.date >= DATE_SUB(NOW(), INTERVAL 90 DAY)
AND t.is_deleted = 0
GROUP BY t.name
HAVING total >= 5
ORDER BY total DESC
LIMIT 20;Documenting the top of that list cuts reopenings and handling time in a measurable way. And measure from the right side: each article's view column counts consultations. An article with many views is paying back the investment; an article with a view count near zero and an old date_mod is a candidate for review or archival - not just one more item in the total.
Maintain it before it ages
A knowledge base is not a project, it is a routine. GLPI keeps history in glpi_knowbaseitems_revisions, so you can edit without fear of losing the previous version. Set a review cadence (quarterly usually suffices), prioritising the most consulted articles - a wrong step-by-step on password reset generates more tickets than its absence. A stale article is not neutral: it costs credibility and the technician goes back to "asking so-and-so".
Need a knowledge base that actually cuts tickets, with search tuned and visibility under control? Discover NexTool's GLPI sustaining service.
Reviewed by the NexTool Solutions team.
