Why a GLPI knowledge base needs targets before launch
A GLPI knowledge base is one module serving two audiences: technicians who need internal procedures and a public FAQ for self-service users of the simplified interface. What decides who sees an article is not the module itself but its targets (entities, groups, profiles or users) combined with its publication state. An article without any target stays unpublished and is visible only to the person who wrote it, so a team that creates content first and assigns audiences later will find that nothing reaches anyone until targets are set. Decide the audience map before the first article is written.
The knowledge base was rewritten in GLPI 12.0.0, which is documented in the GLPI 12.0.0 release on GitHub. Teams starting a knowledge base now should plan their target model against that version, and confirm the behavior of targets, drafts and publication in the version they will run, since the rewrite changes how content is organized. Test the model with one article per audience in a non-production instance before loading the existing wiki or procedures.
Teams usually implement the knowledge base after the helpdesk basics are working, because articles are often linked to ticket categories and the public FAQ depends on how requesters sign in. It is frequently scoped as a separate workstream from helpdesk configuration, with its own owners for content, review and retirement of articles. Agree on who may publish to each entity or group and who reviews drafts before the module goes live, because those decisions are harder to unwind once content is in circulation.
What the GLPI knowledge base does
The GLPI knowledge base holds two kinds of content in one place: internal articles for technicians and a public FAQ for users of the simplified interface. Targeting decides who sees each article, so the audience rules you set at the start determine whether the knowledge base helps or leaks information.
Internal technician articles
Technician articles hold the working knowledge your service desk uses to resolve tickets, such as build steps, vendor contacts and known workarounds. Because they live next to tickets and assets, technicians can find them while working a request. Decide early which teams own each topic and who reviews changes, since articles that go stale quickly erode trust in the whole base. Confirm how your version exposes article search from the ticket view before you plan the content model.
Public FAQ for simplified users
The public FAQ is the part of the knowledge base shown to users of the simplified interface, who request help without working inside the full console. Keep answers to common requests, password and access questions and service hours, and avoid internal procedures or host names. Test the FAQ as an unauthenticated and as a self-service user, because what appears depends on the targets you set and the profiles those users hold.
Targets by entity, group, profile or user
An article without targets stays unpublished and visible only to its writer, so publication is an explicit act. Targets can point to entities, groups, profiles or individual users, which lets one article reach a single regional entity, a support group or a profile class. Map your organization's entities and groups before writing, and check each article against a test user in the audience it is meant for. Overlapping targets are the usual source of unexpected visibility.
Unpublished drafts and review
Drafts without targets remain visible only to the person who wrote them, which gives authors a safe place to work before anything reaches technicians or end users. Define who may publish, who approves wording for the public FAQ and how drafts are reviewed when an author leaves. Without that process, orphaned drafts accumulate and internal content can be published by accident once targets are added.
The GLPI 12.0.0 rewrite
The GLPI 12.0.0 release notes list a rewritten knowledge base among the changes in that release. Plan a test instance and a content export before upgrading, and confirm which article fields, targeting options and public FAQ behaviors carry over in your environment. Do not assume the behavior of 11.x content in 12.0.0 until you have checked it on your own data.
Choosing article targets and audiences
This table compares the four target types GLPI offers for knowledge base articles, plus the public FAQ and unpublished drafts. Read each row for who can reach an article, when that target fits and where it tends to go wrong. The main takeaway is that narrower targets lower the chance of exposing internal procedures, so start narrow and widen only after review.
| Target | Who sees the article | Fits when | Risk or thing to confirm |
|---|---|---|---|
| Entity | Users working in the selected entity, subject to how your version handles sub-entities | Sites, subsidiaries or departments each need their own content | Confirm whether sub-entities inherit visibility before relying on it |
| Group | Members of the selected technician groups | A team such as the service desk or network team shares procedures | Membership changes must be kept current, including any added by directory sync |
| Profile | Users holding the selected profile | Access follows a role, such as technician or administrator | A profile can reach more people than intended, so review which profiles hold knowledge base rights |
| User | Only the named individuals selected | A few reviewers, or content owned by one person | Does not scale, and targets can be orphaned when a person leaves |
| Public FAQ (simplified interface) | Self-service users of the simplified interface who reach the target | Common requests such as how to log a ticket or reset a password | Anything published here is visible to self-service users, so keep internal detail out |
| Internal technician article | Technicians matched by group or profile targets | Runbooks, escalation notes and internal checklists | Targeting by entity alone can expose procedures to people who should not read them |
| No targets (draft) | Only the article's writer | Content under drafting or review | Forgotten drafts stay hidden, so schedule a review before publication |
| Broad target (all entities or all profiles) | Everyone matched by the broad target | General notices that apply to every audience | Widest exposure, so use only for content that is safe for every reader |
Setting up articles for technicians and self-service users
Technicians use the full GLPI interface to search and write internal knowledge: how a service is configured, which workaround applies to a known fault, and which steps the desk follows before escalating. Articles in this group usually describe procedures, troubleshooting paths and configuration notes, and they are often linked from tickets, changes and assets. Targets decide who can read each article, so a technician article should be aimed at the groups, profiles or entities that actually work the related queue, not at every user.
- Article types: Separate procedures, known-error workarounds and reference notes so technicians can filter what they need during an incident.
- Targets: Assign entities, groups, profiles or individual users. Keep internal procedures away from requesters by never targeting the simplified-interface profiles.
- Review step: Agree who checks technical accuracy and who approves publication before an article receives targets.
- Information needed: Include the service name, the owning group, the version or environment it applies to, and the escalation contact.
- Ownership: Record an owner and a review date so stale procedures are visible.
Before you rely on this group, confirm with your own GLPI version which profile rights control knowledge base editing and visibility, because these rights differ between releases and custom profiles.
Self-service users reach the public FAQ through the simplified interface, where they can search answers before opening a ticket. These articles must be written for a reader with no access to internal tools or terminology, and they should answer the questions that generate the most tickets. The public FAQ shows only articles that have targets matching the user, so target selection is what makes an article public. An article without targets stays unpublished and visible only to its writer.
- Article types: Use short question-and-answer articles for common requests, password and access questions, and how-to guides for simple tasks.
- Targets: Target the entities and profiles that should see the answer. Verify that a test user in the simplified interface can find the article.
- Review step: Have the service desk confirm that each answer matches current policy and that it links to the correct request form.
- Information needed: Give the reader the next step, the expected wait, and when to open a ticket instead of waiting.
- Wording: Avoid internal group names, asset identifiers and jargon that a requester would not recognize.
Confirm how your GLPI version presents the public FAQ to the simplified interface, and test with a non-technical account before announcing the page.
The public FAQ depends on the targets set on each article, so target selection is the publication control. During content migration, many imported or rewritten articles will lack correct targets, and leaving them without targets keeps them as unpublished drafts visible only to the writer. This is the safe default: it prevents half-checked answers, outdated procedures or internal notes from reaching requesters before someone has reviewed them. Publication then becomes a deliberate act of assigning targets after review.
- Default state: Import content without targets and publish only after the review step is complete.
- Batch review: Work through migrated articles by owning group so reviewers handle related content together.
- Audit trail: Keep a record of who approved each article and which targets were assigned.
- Retirement: Remove targets from an article that is no longer correct, which returns it to draft status rather than deleting its history.
- Test before release: Check each published article from a simplified-interface account to confirm visibility.
Ask your implementation partner or internal owner to document the migration approach in writing, including who holds the right to assign targets, since this decides who can publish to requesters.
GLPI 12.0.0 was released on October 7, 2026, and its release notes list a rewritten knowledge base. Teams planning an upgrade should treat the knowledge base as its own workstream, because article structure, targets and editing behavior may change compared with the version they run today. Content created in GLPI 11 should be inventoried and tested on a staging copy of the database before the production upgrade, so that targets and visibility are verified rather than assumed.
- Staging test: Restore a copy of production data into a test instance and check that technician and self-service visibility matches your targets.
- Target review: Confirm that entity, group, profile and user targets survive the upgrade with the same meaning.
- Editor training: Brief writers on any changed editing workflow before the upgrade date.
- Public content check: Verify that no draft has gained targets during the migration.
- Rollback plan: Keep a tested backup of the database and files so that a failed knowledge base migration can be reversed.
Read the GLPI 12.0.0 release notes and confirm the exact knowledge base changes with the release documentation before scheduling work, because this summary does not describe every change.
Rolling out a GLPI knowledge base in order
This sequence moves a GLPI knowledge base from version check and audience design to a published public FAQ, with each step producing a record that the next one depends on. Following the order keeps visibility mistakes and unowned content out of production.
Confirm the GLPI version and rewrite scope
Identify the GLPI version you run or plan to run, then decide whether the knowledge base work targets GLPI 12.0.0, which lists a rewritten knowledge base in its release notes, or the current 11.x behavior. Read the 12.0.0 release notes against your current configuration and note any article fields, views or permissions that differ. Confirm with your implementation partner or the release notes which knowledge base features your version supports before you build anything. The output is a short version decision record that names the release line and the features you will rely on.
Define audiences and entity structure
List the groups of readers who will use the knowledge base: technicians by team, managers, and simplified-interface users who need the public FAQ. Map each audience to the GLPI entities that already reflect your organization, such as subsidiaries, sites or business units, and decide where articles should be visible across entities. Keep the entity model aligned with the one used for tickets and assets so targets stay meaningful. The output is an audience matrix that shows, for each audience, the entities and roles that must see its content.
Map profiles and groups that own content
Assign authors, reviewers and publishers to specific profiles and groups in GLPI, rather than to individuals. Check which profiles can create, edit and target knowledge base articles, and confirm that the people who will maintain each topic hold the matching rights. Document who can publish to the public FAQ, since that decision affects what self-service users see. The output is a role table that lists each content area, its owning group, and the profile rights that let members write, review and publish.
Agree the article taxonomy and review process
Define the categories, naming rules and required fields for articles, and decide which categories belong to technician knowledge and which belong to the public FAQ. Write a review process that states who reviews a draft, how long a reviewer has to respond, and what triggers a retirement or update. Keep the taxonomy short enough that authors choose the same category for similar content. The output is an approved taxonomy and a one-page review procedure that the owning groups accept.
Migrate or write a first set of drafts
Start with the articles that resolve the most common requests, either by moving existing wiki pages or by writing them from recent tickets. Save every article without targets so it remains an unpublished draft visible only to its writer, which lets reviewers check content before anyone else sees it. Record the source of each migrated article so the review trail stays clear. The output is a set of drafts in the agreed categories, each with an owner and a reviewer named in the record.
Set targets and test visibility by role
Add targets to each reviewed article, choosing entities, groups, profiles or individual users as the audience matrix requires. Then sign in as a test technician in each relevant group and as a test self-service user, and confirm that each article appears only where intended. Check that unpublished drafts are hidden from everyone except their writer. Test the public FAQ in the simplified interface, because it is the view most end users will see. The output is a visibility test log with each test account, the articles it could see, and any corrections made.
Publish the public FAQ
Move the approved self-service articles to the public FAQ targets and confirm that the publishing group signs off on the final set. Announce the FAQ through the channels your users already read, and link it from the places where they raise requests. Watch for questions the FAQ does not answer during the first weeks, since those gaps shape the next content round. The output is a published FAQ with a named publisher and a list of open content gaps.
Set the ownership and review routine
Assign an owner for each category and set a recurring review schedule that the owning groups agree to, using the cadence your organization can sustain. Include checks for stale articles, broken references, and articles whose targets no longer match current entities or groups. Revisit the routine after each GLPI upgrade, since visibility and rights behavior can change between releases. The output is a maintained review calendar and an ownership register that names a person or group for every published article.
What drives the effort of a knowledge base launch
This table lists the factors that change how much work a GLPI knowledge base launch takes, which costs are paid once and which recur, and what to request in a written quote. Use it to compare your organization's content, audiences and review path against the scope a partner would price.
| Driver | Why it changes effort | How to keep it down |
|---|---|---|
| Entities and sub-entities | Each entity and sub-entity needs its own targeting decisions, so article visibility must be mapped for every branch of the organization. | Publish to top-level entities first and add sub-entity targets only where local content exists. |
| Existing content to migrate or rewrite | Legacy wiki pages, shared drives and old FAQs must be sorted, deduplicated and reworded before they fit GLPI article structure. | Inventory sources before design and retire outdated content instead of moving it. |
| Audiences and profiles | Each group, profile or user target adds a permutation to test, since technicians and simplified-interface users see different content. | Limit the first release to a small set of audiences and expand after feedback. |
| Approval workflow | Drafts that need sign-off from several owners add review steps, role assignments and handoffs that must be designed and tested. | Agree on one reviewer per content area and a fixed review turnaround before launch. |
| Number of reviewers | Every additional reviewer adds reading time, comment cycles and coordination, which scales with article volume. | Name a content owner for each category and keep reviewer lists short. |
| Rewrite for the GLPI 12 knowledge base | Teams on GLPI 12 should confirm which existing articles and settings change under the rewrite before they plan content migration. | Confirm the target version early and plan migration and testing against that release. |
| One-time costs | Design of targets and categories, content migration, test passes with sample users and initial training are paid once at launch. | Ask for each phase as a separate line item in the written scope. |
| Recurring costs | Article upkeep, periodic review, retiring stale content and updating FAQs after product changes continue after go-live. | Assign owners and review dates at launch so upkeep is planned rather than reactive. |
Questions teams ask before building a GLPI knowledge base
How long does a GLPI knowledge base launch take?
The duration depends on how much existing material you have, how many audiences you serve and how many subject-matter owners must review articles before publication. A team with a clear list of topics and a small set of reviewers moves faster than one that starts by sorting years of scattered documents. Confirm the scope in writing with any partner before work starts, since the agreed deliverables and timeline are what set the schedule. No fixed duration applies to every deployment, so ask for a timeline tied to the article inventory, the target audiences and the review steps.
Can an internal team build a GLPI knowledge base without outside help?
Yes, an internal team can build a knowledge base alone if it has someone comfortable with GLPI administration, profiles and entities, and enough time to write and review content. The configuration itself is not the hard part. The effort usually sits in deciding which articles reach which audience, moving content out of old wikis or shared drives, and keeping reviewers engaged after launch. Teams that lack GLPI administration depth, or that need to document a complex entity and profile model, often bring in a partner for the design phase only.
What do subject-matter owners need to provide for a knowledge base?
Subject-matter owners provide accurate procedures, decide who should see each article and confirm when content is out of date. Without named owners, articles go stale and technicians stop trusting the knowledge base. Ask each owner to approve targets for their articles, to name a review cycle, and to agree who retires content. Owners also need time during the build for review sessions, because the audience decision for each article depends on their knowledge of the business.
How do you test article visibility before publishing a GLPI FAQ?
Test visibility with real accounts from each target group rather than relying on administrator views, since administrators often see more than end users. An article without targets stays unpublished and visible only to its writer, so a common failure is an article that looks published to its author but reaches nobody. Create test users that match each entity, group, profile and user target, then check what each one sees in the technician view and the simplified interface. Repeat the check after any change to profiles or entity structure, and record the results as part of your change process.
Does the GLPI 12 knowledge base rewrite change the plan?
Yes, if you plan to run GLPI 12, the rewritten knowledge base in the GLPI 12.0.0 release notes means your article structure, targets and any customizations should be checked against the new version before you build. GLPI 12.0.0 was released on October 7, 2026, according to the glpi-project/glpi releases page. Confirm which version you will deploy, review the release notes for changes that touch knowledge base features, and test a sample of articles and visibility rules on a non-production instance. If you are on GLPI 11, plan the upgrade path as a separate step with its own backup and plugin checks.
How is a fixed-scope GLPI knowledge base engagement agreed?
A fixed-scope engagement is agreed in writing before work starts. The written scope lists the deliverables, the article inventory or content types in scope, the audiences and targets, the testing approach and the timeline. DeployOpen does not publish a price list, so a quote follows from that written scope. When you request one, ask what is included in the scope, what is excluded, what you must provide (such as owner availability and access to the source content) and what happens if the content inventory turns out to be larger than expected.
What recurring work keeps a GLPI knowledge base useful?
Knowledge bases decay without recurring review. Plan for periodic owner reviews, retirement of outdated articles, checks that targets still match the current entity and group structure, and a process for adding new content from resolved tickets. Ongoing support, upgrades and continuous testing are available as retainers, so decide early whether your team will own this work internally or contract it out. Ask any provider how they handle version changes in GLPI and how visibility is retested after profile changes.
How the knowledge base connects to tickets, profiles and identity
A GLPI knowledge base is only as useful as the rules behind it. Articles, tickets, profiles, entities and sign-in sources all decide who sees what, so they should be designed together before anyone writes the first article.
Linking articles to tickets and the catalog
Articles can be attached to tickets and to service catalog items, so a technician working a request sees the procedure next to the form. The useful test is whether the most common requests each have one owner article. Check that the article is linked from the catalog entry and not only from the ticket category, because the self-service user will never see the ticket category. Confirm how your GLPI version presents linked articles to each profile before you rely on the link for self-service.
Profile and group rights for writing
Profile rights decide who can create, edit and publish knowledge base articles, and group membership decides which teams own them. Separate the right to draft from the right to publish, so a technician can propose a change to a procedure without it going live. Review which profiles can publish to the public FAQ, because that audience is outside your technician population. Document the owner group for each article family so edits have a clear approver.
Entities that scope visibility
Entities split a GLPI instance into organizational units, and articles targeted at an entity appear only to users working in it. Use entities for regional IT teams, subsidiaries or client organizations, not for every department. Check whether child entities inherit visibility of parent articles in your configuration, since this is the most common reason an article appears to the wrong audience. Test visibility with one user from each entity before publishing a family of articles.
Authentication sources and sign-in order
GLPI tries sign-in sources in a fixed order: the internal database, then LDAP directories, then IMAP mail servers, then external methods such as REMOTE_USER. This matters for knowledge base access because a user who authenticates through an unexpected source may land in a profile that cannot see the articles they need. Confirm which source each population uses and test sign-in for a sample from each profile. Authentication setup is covered in the GLPI authentication and access control content group.
Content migrated from other systems
Existing wiki pages, shared drive procedures and FAQ exports rarely arrive with GLPI targets, so migrated articles can default to unpublished and disappear from users' view. Map each source collection to an entity, group and profile before import, and remove duplicates and outdated procedures first. Plan a review pass by the owning team, since migrated text often references systems that have changed. The GLPI migrating content group covers the tooling in detail.
What your team provides and what DeployOpen hands over
Your team provides the decisions that shape the knowledge base before any article is written. The most important input is an entity map: the entities GLPI will use, their hierarchy, and which sub-entities need their own technicians and public content. Alongside it, you supply the list of groups and the profiles that will read them, the named content owner for each subject area, and the approval rules that decide who may publish an article and who may only draft one. Existing documentation matters too. Wiki pages, runbooks, shared drives and FAQ text from your service desk should be inventoried with their current owners, so the team can decide what moves into GLPI, what is rewritten and what is retired.
DeployOpen then delivers the configuration and the evidence that it works. The work includes configured article targets by entity, group, profile or user, a written taxonomy of categories, and a tested visibility matrix that shows, for each profile you name, which articles a technician and a simplified-interface user can see. The matrix is run against test accounts in your environment, so you can check the exact result rather than rely on a description. Also handed over are the draft and published content set for the agreed first scope, and a runbook for article upkeep covering who reviews content, how drafts are promoted, and how outdated articles are withdrawn. Where you are on GLPI 12, confirm with your team whether the rewritten knowledge base changes any of these steps before the build starts.
The exact deliverables, acceptance tests and dates are agreed in the written scope before work begins, and nothing is handed over that is not listed there. DeployOpen prepares configuration, test evidence and documentation that your own auditors may examine as part of controls review, but DeployOpen does not issue audit reports, attestations or certifications. Ask for the visibility matrix format and the runbook outline during scoping so you know what you will receive at handover.
How DeployOpen scopes and delivers GLPI knowledge base work
DeployOpen plans, builds, documents and supports GLPI knowledge base work inside infrastructure you control. Each engagement starts from a written scope that sets which audiences, targets and articles are covered before any configuration begins.
How we scope
- We list the technician and self-service audiences, and which entities, groups, profiles or users each article set should reach.
- We agree the article categories, ownership model and review cadence in the written scope before configuration starts.
- Engagements are fixed-scope, so deliverables and timelines are agreed in writing before work begins, with a quote following from that scope.
How we build
- We configure knowledge base targets and profile rights, then test that technicians and simplified-interface users see only what they should.
- We check that unpublished drafts stay visible only to their writers until targets are added, and document the publishing steps.
- Where the GLPI 12 rewritten knowledge base is in scope, we confirm the target version and rebuild content against it in a test instance first.
How we hand over
- You receive written configuration notes covering targets, categories, profile rights and the publishing workflow for article owners.
- We run a walkthrough with administrators and content owners so they can publish, retarget and retire articles without outside help.
- Test results, the public FAQ layout and the list of open decisions are delivered with the final documentation set.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- A retainer can cover knowledge base content reviews, checks after GLPI version updates and changes to targets or profiles.
- Before any GLPI update, we confirm backups of the database, files and configuration keys, and re-test the knowledge base afterwards.
