What the GLPI service catalog gives end users and when to design it
If your users email the service desk or guess which ticket type to pick, the GLPI 11 service catalog is the part of the self-service interface that changes that. According to the GLPI service catalog documentation, the GLPI 11.0 catalog redesigns the self-service interface around hierarchical categories, illustrations and fuzzy search, so a user can browse from a broad group down to the specific service they need instead of reading a flat list of ticket types. The illustrations give each category a recognizable visual anchor, and fuzzy search tolerates typos and partial wording, which matters when people describe a problem in their own words rather than in IT terminology.
The catalog earns its design effort most in multi-entity organizations, where different business units, sites or subsidiaries request different services, and in environments with many request types that users cannot reasonably memorize. It also reduces misrouted tickets, because a user who selects a named service is more likely to land in the right queue than one who chooses from generic categories. Before you commit, confirm with your own support leads which request types are most often reassigned today, since those are the first candidates for a dedicated catalog entry.
The catalog is enabled per entity. In the GLPI interface, open the Helpdesk home tab under Administration > Entities, then set the catalog option for the entity in question. The documentation also describes an inherited option for child entities, so a child entity can follow its parent's setting rather than being configured separately. Decide early whether each child entity should inherit the parent catalog or maintain its own, because that choice determines how many catalogs your administrators must maintain as the entity tree grows.
Catalog configuration options and when each fits
This table compares the GLPI 11 service catalog settings that shape what end users see, from per-entity enablement to inherited settings and search behavior. Read each row as a decision: the situation it suits and what to confirm in your own instance before you rely on it.
| Option | What it controls | When it fits |
|---|---|---|
| Per-entity enablement | Turns the catalog on or off for each entity from the Helpdesk home tab under Administration > Entities | Use when only some business units or customers should see catalog services, and others keep the classic helpdesk view |
| Inherited option for child entities | Lets a child entity follow the setting of its parent instead of holding its own value | Use in multi-entity trees where one catalog policy should cascade, and override only where a child needs a different offer |
| Explicit setting on child entities | Holds a local catalog value that does not change when the parent changes | Use for subsidiaries or managed clients with separate service offers, and document each override so it is not lost during changes |
| Category depth | Hierarchical categories that group services into levels users navigate | Use shallow trees for small catalogs; add levels only when users can find services faster, and confirm how many levels your version displays well |
| Illustrations on categories and services | Images attached to catalog entries to help users recognize options | Use where users pick from visually distinct services; confirm supported file types and sizes in your GLPI version before standardizing images |
| Fuzzy search | Matches close or misspelled terms in the catalog search | Use when end users describe problems in their own words; test with real request titles from your ticket history |
| Search settings and visibility | Controls which services and categories appear to a given user profile or entity | Use when access must follow roles; verify visibility with test accounts from each profile before launch |
| Native forms published as services | Exposes a form in the core as a catalog entry that opens a ticket with mapped answers | Use for standard requests with predictable fields; confirm how answers map to ticket fields in your instance |
Design decisions to settle before publishing services
The GLPI 11 catalog is only as useful as its structure. Each decision below shapes what users see, who maintains it, and how child entities inherit it, so settle them before the first service goes live.
Which entities expose the catalog
The catalog is enabled per entity from the Helpdesk home tab under Administration > Entities, and child entities can inherit the setting. Decide which entities should show the catalog and which should keep the classic helpdesk. Inheritance keeps large trees consistent, but a child entity that inherits a setting it does not need will show requests that do not apply to its users. Check each entity's requesters before you enable or inherit.
Categories that mirror user intent
Categories should follow how users describe their problems, such as "I need software" or "my laptop is slow", rather than the teams that resolve them. Team-shaped categories force users to guess which group owns their request and produce misrouted tickets. Test category names with a few real requesters before building the hierarchy, and keep the depth shallow enough that a user can reach a service in a few clicks.
Services versus knowledge base articles
Not every question needs a request. Requests that change something, grant access or need approval belong in the catalog as services. Questions that users can resolve themselves, such as password reset steps or VPN setup, belong in knowledge base articles linked from the portal. Mixing the two inflates the catalog and buries the forms people actually submit, so review each candidate against whether a technician must act.
Ownership of wording and illustrations
Someone must own the service names, descriptions, search terms and illustrations, and approve changes. Without an owner, wording drifts between teams and entities, and users see inconsistent names for the same request. Agree who edits text, who supplies images, and how changes are reviewed before publication. Ask your GLPI partner or internal administrator to confirm where each of these settings is applied in your version.
Search terms and fuzzy matching
Fuzzy search helps users find services with imperfect wording, but it also surfaces unrelated results when service names are vague. Decide which synonyms, abbreviations and internal product names users actually type, and record them in service descriptions. Test searches with the vocabulary of the people who will use the portal, not the vocabulary of the service desk.
Published forms and their owners
A native form published as a service is a contract with the people who answer it. Each published form needs a named owner who decides when questions change and who checks that answers still map to the right ticket fields. Stale forms that point at retired groups are a common failure, so set a review date for each service at publication.
Single entity versus multi-entity inheritance
In a single-entity GLPI, there is one set of users, one set of technicians and one catalog owner, so the design work centers on what to publish rather than where it applies. The catalog is enabled for the one entity from the Helpdesk home tab under Administration > Entities, and the team maintains categories, illustrations and published forms in one place. Most decisions here concern scope and clarity.
- One named catalog owner: Assign a person who approves new services, category changes and wording, so requests do not drift between teams.
- A shallow category tree: Keep the hierarchy short enough that a requester reaches the right service in a few clicks.
- Illustrations and labels: Choose images and service names that match the words staff already use when they ask for help.
- Search behavior: Test fuzzy search with phrases taken from your past ticket titles, not with the names your team uses internally.
- Publication order: Publish a small set of high-volume services first, then expand once feedback shows the layout works.
Before publishing to all users, sign in as a test requester with the same profile your end users hold and confirm that every service is visible and opens the correct form.
In a multi-entity GLPI, entities separate data, administration and visibility, and each child entity can inherit the catalog settings of its parent. Inheritance is the option that makes a shared catalog maintainable, because a change made once at the parent flows to children that follow it. The GLPI 11 service catalog documentation describes the inherited option as part of enabling the catalog per entity, so the setting for each child should be checked rather than assumed. For background on the feature, read the GLPI documentation: Service Catalog.
- Central publishing: Build shared categories and services at the parent so every inheriting child offers the same baseline.
- Explicit inheritance per child: Set the inherited option deliberately on each child entity, and record which children follow the parent.
- Entity-specific audiences: Confirm that users in each child only see services their entity should offer, because visibility follows entity membership and profile.
- Administrator scope: Limit who can edit parent catalog content, since one change can reach many child entities at once.
- Clear ownership split: Decide which team owns shared services and which local administrators own child-only additions.
In each child entity, confirm which setting is in effect before you assume the child matches the parent.
A child entity should override the inherited catalog only when its users need something the parent cannot serve. An override stops the child from following the parent for that setting, so later parent changes no longer reach it automatically. Every override is a second catalog to maintain, so treat each one as a decision that needs a reason, an owner and a review date.
- Different service set: An entity that runs its own applications or hardware may need services the parent does not offer (illustrative: a regional site with a local building access system).
- Different support model: A child with its own technicians or service hours may need different categories or wording to route requests correctly.
- Language or local terms: A child serving another language or jurisdiction may need translated names and illustrations.
- Separated teams or regulated data: A child that must keep its request content apart from other entities may need its own published services.
- Minimal overrides: Keep the number of overriding children and changed items low, and review them after each parent release.
Record each override with its reason, owner and the parent setting it replaces, so future parent changes are reviewed against it.
A change at the parent can alter what every inheriting child user sees, so testing should start there and cover each entity type. Overriding children will not change from a parent edit, so they need a separate check to confirm that they still behave as intended. A short, repeatable test script is more useful than a one-time review because catalog changes tend to arrive in small steps.
- One test requester per entity: Use a dedicated account in each entity, with the same profile as a real requester, to see what that user sees.
- Category walk-through: Open every category level and confirm each path leads to the intended service and form.
- Search checks: Run searches with realistic request phrases and confirm the expected service appears near the top.
- Override comparison: For overriding children, confirm the catalog still matches their recorded override and was not changed by the parent edit.
- Ticket routing: Submit a test request from each entity and confirm it lands in the correct entity, category and technician queue.
Keep the script with the catalog change record, and run it after every parent change before announcing the update to users.
Publishing native forms as catalog services
A native GLPI 11 form becomes visible to end users in the service catalog only after you publish it as a service, so the publishing step is where form design turns into the request experience people actually see. Treat each published form as a contract: the questions on the form decide what the requester must supply, and the way those answers land in the ticket decides whether technicians can act on the request without a follow-up email. Plan both ends before you publish anything, and confirm the exact publishing path, menu names and field options for your GLPI version in the GLPI documentation for the service catalog because the interface changed between releases.
Map every requester-facing question to a ticket outcome. Decide which answers populate the ticket title, description, category, urgency, location or assignee, and which are only kept as context in the description. Be explicit about required questions, since an unanswered mandatory field is the most common reason a request arrives incomplete. Test the mapping with a few sample submissions from each entity that will offer the service, and check the resulting tickets as a technician would see them. Confirm with your GLPI version how ticket fields are filled from form answers and whether the mapping can be changed after the service has live submissions, because that determines how cautiously you should pilot.
Review sets the boundaries of this page. It covers how the catalog presents a published form, how the answers flow into tickets and how entity inheritance decides where a service appears. The sibling topic on native forms for service requests covers building the form itself in the interactive editor, and the sibling on customizing the helpdesk portal covers tiles, entry points and knowledge base placement. Technician-only questions, which requesters never see, and the Advanced Forms plugin are covered in that native forms topic, so do not design those questions here. Before rollout, confirm in your environment which publishing options your version offers and test them on a non-production instance.
How to set up the service catalog in GLPI 11
This sequence takes a GLPI 11 instance from a confirmed version and upgrade path to a service catalog that a standard end user can search, browse and submit from, with child entities checked for inherited settings. Each step closes with a check so the team knows it can move on.
Confirm the GLPI 11 version and upgrade path
The platform owner confirms which GLPI version the instance runs and whether it is already on the 11.x line. The service catalog described here belongs to GLPI 11.0, so an instance on 10.x needs its upgrade completed first. Check the database and PHP requirements against the GLPI installation prerequisites, and confirm that plugins you rely on are supported on the target version, because GLPI 11 suspends plugins after a new version is detected and they must be reactivated after major updates. Done when the running version is recorded, the upgrade backlog is agreed, and a test copy of the instance is available for the catalog build.
Enable the catalog for the target entity
An administrator opens Administration > Entities, selects the entity that will host the self-service portal, and turns on the service catalog from the Helpdesk home tab. Decide at this point whether child entities should inherit the setting, because the inherited option is applied per entity. Keep the production change window and the rollback plan in the change record. Done when the target entity shows the catalog as enabled and a user from that entity can open the portal without an error.
Build categories and illustrations
The service owner defines the hierarchical categories that end users will browse, such as access, hardware, software and workplace, and adds an illustration to each category that needs one. Keep the top level short enough to scan on a phone and make sure each leaf category maps to a team that will own the resulting tickets. Done when every category has a clear name, a parent where needed, an owner, and a sample user can reach each leaf in no more than a few clicks.
Configure search for the portal
The administrator reviews the catalog search settings and tests fuzzy matching with the terms users actually type, such as common misspellings of software names or device types. Compare the results with the wording used in the categories and the titles of the forms you plan to publish, and add plain-language descriptions where a request is hard to find. Done when a test list of twenty or so realistic queries returns the intended service in the top results, and gaps are logged for the content owner to fix.
Publish native forms as services
The form owner selects each native form that should appear as a service, assigns it to the right category, and checks that the answers map to the ticket fields the receiving team needs. Confirm which questions are visible to end users and keep technician-only questions out of the public form. Done when each published service opens for a test user, submits a ticket, and the ticket lands in the expected queue with the expected category and urgency.
Test as a standard end user
A tester with a standard end-user profile, not a technician or administrator profile, signs in and works through the portal from a clean session. The test covers browsing categories, searching, opening illustrations, submitting each published service and checking the confirmation and ticket status. Record any service that is visible when it should be hidden, and any permission error that blocks a valid request. Done when the test script passes for every published service and the list of defects is closed or accepted by the owner.
Test inheritance in a child entity
The administrator signs in as a user in a child entity and confirms whether the catalog appears according to the inheritance choice made in the parent entity. Check that the categories, services and search results match the intended design, and that no service from a sibling entity leaks through. Repeat the standard end-user test here, because entity-level visibility is where multi-entity setups most often drift. Done when the inheritance behavior matches the written design for every child entity in scope and the results are recorded in the change record.
Security and access considerations for the self-service portal
The catalog is only as safe as the rules behind it. Visibility depends on profiles, entity scope and the way the portal is reached, so each of these controls needs to be set and checked on purpose. The cards below cover what to decide before publishing and what to verify after.
Profile and entity visibility
Service catalog visibility follows the profile and entity a user belongs to, so a service published in one entity can be seen by people in other entities if the inheritance setting allows it. Map each catalog item to the groups and entities that should see it, then test with a standard requester account from each entity. Confirm that the inherited option behaves as you expect for child entities before you rely on it.
Keeping internal services out
Some services exist only for technicians, such as privileged access requests or changes to production systems. Publishing them to the catalog exposes their names and purpose to every requester who can reach the portal. Keep internal-only items in a separate entity or out of the catalog entirely, and review the list of published services at each change window.
Reviewing published wording
Service names, descriptions and illustrations are visible to all users who can open the catalog, so they should not reveal system names, internal hostnames, vendor contract details or staffing structures. Have someone outside the service desk read each published entry as an end user would. Treat the wording as a document that needs an owner and a review date.
Portal behind the chosen login method
The portal should sit behind the authentication method your organization has selected, whether that is GLPI's internal database, LDAP, or an external method. GLPI documents its authentication order as internal database, then LDAP directories, then IMAP mail servers, then other external methods such as REMOTE_USER. Confirm which method handles each user type, because a fallback to the internal database can admit accounts that your directory would have blocked.
Verifying access rules in your environment
The documented order and profile model describe how GLPI is designed to behave, not how your instance is configured. Write a short test plan with accounts for each role, entity and login path, and record what each account can see in the catalog and the portal. Repeat the test after upgrades, directory changes and any new entity, since these are the events that most often shift visibility.
Questions buyers ask before setting up the GLPI service catalog
How much effort does a GLPI service catalog build take?
The effort depends mainly on how many services you publish, how many entities need their own catalog, how complex each request form is, and how many approval steps sit behind each service. A catalog with a handful of services in one entity is a small workstream. A catalog with dozens of services across several child entities, each with its own categories, illustrations and approval routing, is a much larger one. Ask any partner to size the work from a written list of services, forms and entities, not from a general description. We provide that sizing only in a written scope, so you can compare it with what your own team would need to do.
Can our own team build the GLPI service catalog in-house?
Often yes, if you have someone who knows GLPI administration, the entity structure and your request workflows. The catalog itself is configured through the Helpdesk home tab and the entity settings, so the technical steps are not the hard part. The harder parts are agreeing on service names, deciding what belongs in which category, and testing every path a requester can take. Teams that build in-house usually underestimate the review cycle. Decide early which work you will keep, such as category design and wording, and which you will hand to a partner, such as form publishing across entities or testing with real users.
What does our team need to provide for the catalog work?
The catalog goes wrong most often when no one owns the content. Plan for three roles. Catalog owners decide which services are offered and who maintains each one. Reviewers check the wording of service names, descriptions and form questions against how your staff actually ask for help. Test users, drawn from several departments and entities, submit requests end to end and report where the path breaks. Confirm named people for each role, the time they can give during build and testing, and who signs off before go-live.
Does the GLPI service catalog require an upgrade to GLPI 11 first?
Yes. The catalog described in the GLPI service catalog documentation is the GLPI 11.0 redesign of the self-service interface, with hierarchical categories, illustrations and fuzzy search. A GLPI 10 instance does not have this catalog, so the upgrade comes first. Before you upgrade, back up the database, the files and the config directory, including glpi.key and glpicrypt.key. After the update, run the database update step and reactivate plugins, because since GLPI 11.0 plugins are suspended when a new version is detected. Check plugin compatibility before you plan the catalog content, since plugin-based forms may need a separate migration.
How do multi-entity setups handle the service catalog?
The catalog is enabled per entity from the Helpdesk home tab under Administration > Entities, and child entities can inherit that setting. Inheritance saves work when several child entities share the same services, but it also means a change at the parent reaches every child that inherits it. Decide which services are global and which belong to one entity before you enable anything. Test a request from a child entity user to confirm they see only the services intended for them.
What should we ask for in a fixed-scope quote for the catalog?
DeployOpen works from a written scope, and most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ask the quote to list the number of services and categories, the entities in scope, the number of request forms and their approval steps, the wording review cycle, the test rounds and who runs them, and the handover material. Ask what is excluded, such as plugin migration, form design for technician-only questions, or support after go-live. Ask whether ongoing support is priced separately, since retainers cover support and continuous work after the initial build.
What breaks after the catalog goes live, and how do we check for it?
The common failures are services that point to forms nobody maintains, categories that users cannot find through search, and child entities that show services they should not see. Build a short checklist for each release: submit one request per service from a test account in each entity, confirm the search returns the expected service for common phrases, and confirm approvals route to the right group. Repeat the checks after any GLPI upgrade, since the catalog is part of the interface that upgrades change. Assign one owner to run this checklist on a fixed schedule.
How DeployOpen works on this
DeployOpen scopes, builds, documents and supports GLPI service catalog and self-service portal inside infrastructure you control. We start from the services your users need, then configure the catalog per entity, test what end users actually see, and hand over a catalog your technicians can maintain.
How we scope
- Inventory the request types, entities and user groups that should appear in the catalog.
- Confirm which GLPI 11 entities enable the catalog and which child entities inherit it.
- Agree in writing which native forms, categories and illustrations are included in the fixed scope.
- Record which pieces of the self-service portal are out of scope, such as custom integrations or plugins.
How we build
- Configure categories, illustrations and search settings in a non-production GLPI instance first.
- Publish native forms as catalog services and map each answer to the ticket fields technicians use.
- Test the catalog from end user accounts in each entity, including inheritance and permission boundaries.
- Confirm the GLPI version and PHP and database requirements before any build work starts.
How we hand over
- Document the catalog model, the entity settings and who owns each category and service.
- Provide a walkthrough so administrators can add services without breaking inheritance.
- Deliver a test script that repeats the end user checks after each change or upgrade.
- Agree the handover record and open items in writing before the engagement closes.
How we support
- Offer ongoing support, upgrades and testing as a retainer after the fixed-scope delivery.
- Review catalog changes and GLPI release notes before applying updates to production.
- Plan updates with a database, file and configuration backup as part of the change record.
- Confirm support terms, response expectations and included hours in the retainer quote.
