How customizing the GLPI helpdesk portal shapes self-service
A service desk works best when users have one clear place to report a problem, ask for something new and find an answer before they open a ticket. In GLPI, that place is the helpdesk portal, the hub where self-service profile users report incidents, submit service requests, consult the knowledge base and reserve resources. The portal is not a fixed page. It can be shaped so that each group of users sees the entry points that apply to them, and the work of shaping it is usually the difference between a portal people use and one they bypass by emailing a technician directly. The reference for the portal's current behavior is the GLPI 12 helpdesk portal documentation, which you should read against the exact version you plan to run.
Teams usually need this work in three situations. The first is when one GLPI instance serves several organizations or entities, each with its own catalog, contacts and knowledge articles that should not appear to everyone. The second is when the user population is mixed, such as office staff who log in with a directory account, field staff who rarely sign in, and external contractors with limited access. The third is when the same questions arrive again and again, such as password resets, VPN access or laptop requests. In each case, the decisions are concrete: which entry points each profile sees, which knowledge base articles are published to which audience, which reservable assets appear to which users, and which tiles or links lead to the right form. Before changing anything, list the top ten request types from your current ticket history and confirm which of them your portal can already route without custom work.
Plan the portal as a design exercise, not a theme change. Map each user group to its profile and entity, decide what each group should be able to start from the portal, and test the result with a real user from each group using a non-production copy. Confirm with your GLPI administrator which settings are global and which can be set per entity, because that determines how much work a multi-entity rollout creates. Also confirm how the portal behaves for users who sign in through an external method, since the authentication order in your deployment affects who reaches the portal and under which profile. A portal that matches these decisions is easier to maintain, and it is the part of the GLPI rollout that your end users will judge first.
Which entry points each organization needs
A single-organization deployment has one set of users, one set of services and usually one support model, so the portal can stay relatively simple. The main job is to keep the entry points users actually need visible and remove the ones that only technicians should use. Start from the list of request types your service desk already handles and map each one to a portal entry point, rather than enabling everything GLPI offers by default.
- Incident entry point: Keep it visible for all employees, since it is the path for breakage and should be the most obvious action.
- Service request entry points: Expose common requests such as access, hardware or software, and hide internal change or project requests that employees should not raise directly.
- Knowledge base access: Show articles that answer frequent questions, and restrict internal runbooks or technician notes to technician profiles.
- Reservation options: Expose loaner or shared equipment only if a reservable pool exists and someone owns its approvals.
- Hidden items: Hide anything that duplicates another entry point, since duplicate tiles increase misrouted tickets.
Before go-live, confirm the exact menu items and tile names in your GLPI version against the GLPI 12 helpdesk portal documentation, and test the portal with a standard employee profile.
In a multi-entity deployment, several legal entities, departments or sites share one GLPI instance but need different services and knowledge. The portal decision is less about what exists and more about what each entity should see. Users in one entity should not be offered request types, articles or reservable assets that belong to another, and entity-level settings determine much of that visibility. Plan the entity tree first, then decide which entry points each branch inherits and which it overrides.
- Shared entry points: Keep the incident path and general requests at the top level so every entity has a consistent way to report problems.
- Entity-specific requests: Publish requests that only one entity uses, such as site facilities or regional procurement, at that entity level.
- Knowledge base scope: Decide which articles are global and which are local, and confirm that local articles do not appear to users in other entities.
- Reservations by site: Make loaner pools reservable only within the site that holds the equipment.
- Inheritance checks: Confirm how child entities inherit portal settings in your version, because a change at the parent can expose items you meant to keep local.
Ask your implementation partner or GLPI administrator to document the visibility matrix for each entity and to test it with a user from every branch.
Some deployments serve contractors, students, volunteers, partner staff or customers who are not employees. These users need access to a narrower set of entry points, and the portal should not expose internal service desk processes to them. The right choice depends on how these users authenticate and which profile they receive, so the entry point design should follow the access model rather than the other way round. Treat external users as a distinct audience with their own tile set and knowledge base view.
- Incident and request entry points: Limit external users to the request types you have agreed to support for them, and hide internal requests such as privileged access or asset disposal.
- Knowledge base access: Publish only articles written for external audiences, and keep internal procedures and security details out of their view.
- Reservation options: Expose reservations only where external users are meant to borrow equipment, and require an approval step that matches your policy.
- Account and profile mapping: Confirm which profile and entity external users land in, because that determines what the portal shows them.
- Information exposure: Review ticket fields and notifications so that internal notes and asset details are not shown to external requesters.
Before granting access, verify the portal with a test account for each external user type and confirm the exact menu items in your GLPI version.
Portal options and when each fits
This table compares the main ways to shape the GLPI helpdesk portal: entry points for incidents and requests, knowledge base visibility, reservations, per-organization tiles and profile-based visibility. Read each row for what changes for the user, what GLPI setting it depends on and when a team should choose it. Options marked for confirmation depend on your GLPI version and should be checked against the documentation for that release before you commit to a design.
| Option | What changes for the user | What it depends on in GLPI | When to choose it |
|---|---|---|---|
| Incident entry point | Users report a broken service or outage from a dedicated path in the portal | Helpdesk portal enabled, ticket types and categories defined for incidents | Choose it when the portal is the main channel for outages and users need a clear way to report faults |
| Request entry point | Users ask for standard services, such as access or equipment, from the portal | Request types and categories, plus any forms or service catalog items you publish | Choose it when routine requests should reach the right queue without an incident being raised first |
| Knowledge base visibility | Users find articles before they open a ticket, and can see only the articles their profile allows | Knowledge base items with visibility set by target audience, profile or entity | Choose it when many repeat questions can be answered by an article, and when some content must stay internal |
| Reservations | Users book loaner or shared resources such as laptops or projectors from the portal | Reservable assets and reservation settings; confirm the reservation options available in your version | Choose it when loaner pools exist and users would otherwise request them by email or phone |
| Tiles per organization | Each department or entity sees its own links, entry points and services | Entity structure and the portal layout settings for each entity; confirm inheritance behavior in your version | Choose it when business units differ in services, contacts or approved request types |
| Profile-based visibility | Users see only the portal items that their profile permits | Profiles, rights assignment and entity access, which should be set before the portal design is tested | Choose it when some options, such as privileged requests, must be limited to specific groups of users |
| Validation and testing effort | Each option must be checked from the view of every profile that will use it | Test accounts for each profile and entity, with sample tickets and articles | Plan testing time for every option you enable, since a visibility error can expose internal content |
How to set up the portal in order
This sequence takes the portal from a confirmed GLPI version and profile model to a tailored self-service view for each organization or entity, checked profile by profile. Each step ends with a check you can repeat after any later change.
Confirm the GLPI version and profiles
Start by recording which GLPI version runs in your environment and which profiles exist, such as self-service users, technicians and administrators. Your GLPI administrator should check the version under the administration area and list each profile with its rights, since the portal shows different content depending on the profile a user holds. Confirm whether a version upgrade is planned, because portal options and layout can change between releases and should be checked on the version you will run. You know this step is done when you have a written list of versions and profiles that every later step refers to.
Define which users see the portal
Decide which accounts should land on the self-service portal and which should use the standard technician interface. Your GLPI administrator sets the default interface for each profile and checks how users are assigned to profiles, including any profiles created by directory group mapping. Agree this with the service desk lead and the identity team, because the answer depends on how users authenticate. You know this step is done when every profile has a stated default interface and the list is signed off.
Configure entry points and knowledge base access
Set up the entry points users will use to report an incident or submit a service request, and decide which knowledge base articles each profile can read. Your GLPI administrator enables the knowledge base for the self-service profile and confirms that only articles marked for that audience appear. Review the entry points with a sample of real request types so that users do not face an empty or confusing form. You know this step is done when a test user from the self-service profile can open each entry point and see only the articles intended for them.
Add reservations if your organization uses them
If loaner equipment or shared resources are reserved through GLPI, enable reservation tiles only for the profiles and entities that need them. Your GLPI administrator makes the relevant assets reservable and confirms the reservation options that appear in the portal. Skip this step if no resources are reserved, and mark it as not applicable in your plan. You know this step is done when a test user can see the reservation tile, make a booking for a reservable asset, and see the booking reflected in the asset record.
Tailor tiles per organization or entity
In a multi-entity GLPI, adjust which tiles and services appear for each organization or entity so that users see only what applies to them. Your GLPI administrator uses entity settings and the portal configuration for each entity, and records which settings are inherited from parent entities and which are overridden. Confirm this with the owners of each entity, because a change in a parent entity can affect child entities. You know this step is done when the configuration for each entity is documented and a user in each entity sees the tiles agreed for that entity.
Test as each profile before release
Sign in as a test user from every profile and entity you configured, and record what appears on the portal for each one. Check that entry points, knowledge base articles, reservation tiles and entity tiles match the plan from the earlier steps, and that no user sees content meant for another profile or entity. Repeat the test after any upgrade, plugin change or directory group change. You know this step is done when every test account matches the written plan and the results are kept with the configuration record.
Security and access considerations for portal changes
A portal change is only as safe as the rights behind it. The cards below cover what self-service users can reach, how profiles and entities narrow that reach, how changes get tested before release, and how GLPI 12 session controls apply to portal users.
Knowledge base visibility
Knowledge base articles carry their own visibility settings, so an article hidden from the internal team can still reach end users if it is published to the portal. Review every entry point and article against the audience it targets, including articles linked from tiles or ticket templates. Check that drafts and internal procedures do not appear in search results for self-service profiles. Test with a real self-service account, not an administrator, before each release.
Profile and entity rights
Self-service users see only what their profile allows, and entities determine which requests, categories and assets belong to which organization. A tile that is visible to every user but points to a form restricted to one entity creates confusing dead ends and can expose naming of other units. Map each tile to the profile and entity that should see it, and confirm that child entities inherit only the settings you intend. Ask your GLPI administrator to document the rights matrix before you change the portal layout.
Entry point exposure
Each incident or request entry point is a way into the ticketing workflow, so an overly broad form can route sensitive requests to the wrong queue or collect data that should not be captured in plain text. Review which fields are mandatory, which categories are offered, and whether any form asks for personal or security-sensitive details. Remove legacy entry points that still route to closed queues, since they keep working paths that no one monitors.
Change testing and review
Treat portal configuration as code-like change: draft it in a staging instance built from a recent copy of the configuration, test each tile and form with a set of representative test profiles, and have a second administrator approve the change. Record who approved each change and keep the previous configuration so it can be restored. Confirm with your partner or internal team how staging data is sanitized before it is copied from production.
Session view and step-up
GLPI 12 adds a view of active user sessions with the ability to revoke them, and step-up authentication for certain administrative actions. These controls are aimed at administrators, but a portal user with a compromised session can still raise tickets, read articles and reserve resources, so revocation procedures should cover self-service accounts too. Confirm which actions require step-up in your release and whether they apply to any profile that can edit portal content. For how to use the session view, see the sibling topic on GLPI 12 active user sessions and session revocation.
Two-factor and external sign-in
How users authenticate changes what a portal session can reach, because a portal account signed in through an external directory inherits that directory's protections. Decide which self-service profiles must use a second factor before they can open requests for sensitive services. Two-factor enrollment, enforcement and its interaction with external authentication are covered in the sibling topic on TOTP two-factor authentication, so align those decisions before you publish a restricted entry point.
Questions teams ask before customizing the portal
How much effort does customizing the GLPI helpdesk portal take?
Effort depends mainly on how many entities, profiles and entry points the portal must serve, and on how much knowledge base content is ready to publish. A single entity with two or three profiles and a short list of request types is a small piece of work. Each additional entity adds its own tiles, visibility rules and testing, and each extra profile multiplies the cases someone has to verify. Thin or outdated knowledge articles also add work, because the portal can only point users to content that already exists and is accurate. Ask any provider to break the quote into entities, profiles, entry points and content review so you can see which line items grow with your organization.
Can our internal team customize the helpdesk portal without a partner?
Yes, many teams do this in house, provided one or two people understand GLPI profiles, entities and the portal configuration, and can test changes with real user accounts before release. The risk is usually not the configuration itself but the lack of a repeatable test pass across profiles, and the upgrade effect on later GLPI versions. Before deciding, check whether your staff have time for design decisions, testing and documentation, and whether someone owns the portal after the first release. A partner is most useful when the design needs to be settled quickly or when the team wants a documented build it can maintain.
What do we need to provide before the work starts?
The work moves faster when you provide a current list of user profiles and the people who hold them, the ticket categories your service desk actually uses, and a named owner for each knowledge base section. You should also supply a set of test users, one per profile, who can sign in to a non-production copy of the portal and report whether each tile, form and article behaves as expected. Confirm which entities and departments need different entry points, and who approves the final layout. Missing ownership for knowledge content is the most common cause of delay, because published articles need someone accountable for keeping them correct.
How long does a portal customization take?
Duration depends on scope, so no figure is given here. The main drivers are the number of entities and profiles, whether new request forms must be designed, how much knowledge base content needs review, and how quickly your stakeholders approve the layout and test results. Ask any provider for a timeline that is tied to a written scope with named deliverables and a testing phase, and ask which of your reviews or content tasks sit on the critical path. Also confirm whether the work includes a non-production environment, since testing in production extends the calendar and increases risk.
Which portal changes can affect security or access?
Changes to tiles, entry points and knowledge base visibility determine what each profile can see, so they should be reviewed as access changes, not only as cosmetic edits. Check that profiles, entities and visibility rules do not expose internal articles, reservations or ticket categories to users outside their scope. If your organization uses single sign-on or external authentication, confirm how portal users are mapped to profiles before you publish tiles that depend on those roles. Ask for a test matrix that shows which profile sees which entry point, and keep it with your change records.
Does customizing the portal change how we upgrade GLPI later?
Portal customizations should be documented so they can be checked after each GLPI update, since the interface and its configuration options can change between releases. Any custom code or plugin used for the portal may need reactivation or adjustment after a major update, and the update procedure requires backups of the database, files and configuration keys before application files are replaced. Confirm with your provider which parts of the design are configuration only and which depend on plugins or code, and plan a test pass on a copy of the instance before each upgrade. Your GLPI version and plugin list should be recorded at handover so the next upgrade starts from known facts.
What should we check in a proposal for this work?
A useful proposal states the entities, profiles, entry points and knowledge base sections in scope, lists the deliverables and the test evidence you will receive, and names who performs each task. It should separate one-time design and build work from any recurring review, content maintenance or upgrade testing you choose to buy. Ask how user acceptance testing is run, what happens to changes requested after sign-off, and what documentation you keep. Finally, confirm the environment the work will run in and whether any third party needs access. Fixed-scope proposals with written deliverables make these points easier to compare across providers.
Limits to confirm in your environment
The helpdesk portal changes between GLPI releases, and a tile layout that works in one entity may not carry into another. Each card below names a limit to check against the GLPI version you run, using the vendor documentation or a test instance before you publish anything to users.
Portal options in GLPI 11 and 12
Confirm which portal entry points, tile types and knowledge base views exist in the release you plan to run. GLPI 12 is a separate major line from GLPI 11, so a layout built on one may not map cleanly to the other. Check the helpdesk portal options in your exact version against the GLPI 12 documentation and a staging instance, and record any option you depend on that is missing or renamed.
Tile behavior in multi-entity setups
Tiles and their visibility can depend on the entity a user belongs to, and child entities may inherit or override parent settings. Test with at least one user from each entity and profile combination you support. Confirm whether a tile hidden in a parent entity can reappear in a child, and whether reservations and knowledge base content follow the same rules.
Plugin reactivation after updates
Since GLPI 11, plugins are suspended after a new version is detected and must be reactivated after major updates. A customized portal that relies on a plugin-provided tile or form can disappear until that plugin is reactivated and checked. Schedule the reactivation step in your upgrade runbook, and confirm with each plugin's maintainer that it supports the target GLPI version.
Browser and accessibility behavior
Portal pages rely on the browsers and assistive technologies your users run, and accessibility work changes between releases. Test the incident, request and knowledge base paths with your supported browsers, keyboard-only navigation and a screen reader. Ask the vendor which accessibility improvements ship in your target version and which known gaps remain.
Update and backup dependencies
Portal customizations live in the database and configuration, so an update can change them. Confirm which settings are preserved by the update procedure, and keep a backup of the database, files and the config directory that includes glpi.key and glpicrypt.key before you change any portal setting. Restoring a portal layout should be tested on a copy of production data.
Authentication and visibility rules
What a user sees in the portal depends on the profile and authentication source that signed them in. Confirm how tiles and knowledge base entries behave for users authenticated through LDAP, external methods or SSO, since authentication sources are tried in a fixed order. Test users from each source against each tile to avoid exposing content to the wrong group.
Keeping the portal current after upgrades
Every GLPI upgrade needs a review of the helpdesk portal, not just the database and application files. Tiles, entry points, knowledge base visibility and the profiles that decide what self-service users can see can all shift when the platform changes, so the portal configuration should be checked as a deliverable of each upgrade. Before production changes, ask who owns the portal settings, which profiles are used by self-service users, and which knowledge base articles are published to them, then record that inventory so the post-upgrade check has something to compare against.
Backups come first. The GLPI update procedure requires backing up the database, the files and the config directory, and the config directory must include glpi.key and glpicrypt.key. Without those keys, encrypted values stored in the database may not be readable after a restore, so a backup that omits them is not a usable rollback point. Confirm the backup has been restored successfully in a test environment, not only that the archive was created. The GLPI installation docs on updating set out the steps and the database update command that runs after the files are replaced.
A staging copy of the production instance is the practical gate before any change reaches users. Run the update there, reactivate plugins (since GLPI 11.0 suspends them when a new version is detected and they must be reactivated after major updates), then walk the portal as a representative self-service user. Check that incident and request entry points open the right forms, that knowledge base articles display for the intended audience, and that reservation and organization-specific tiles still resolve. Record any differences and decide, before release, whether they need a configuration fix or a communication to users. The staging result should be the go or no-go input for the production window.
How DeployOpen scopes portal customization
Portal customization is scoped as a fixed piece of work agreed in writing before build starts. The cards below cover what the scope holds, what you receive, where the work runs and how support continues after go-live.
Scope the entry points first
The written scope names every entry point the portal will expose: incident reporting, service requests, knowledge base access and reservations. For each one it records which profiles see it, which entity it applies to and what the user lands on after submitting. Ask for this list as a numbered table before any configuration starts, because it becomes the baseline for acceptance testing. Confirm which entry points your version of the helpdesk portal supports and which need a plugin.
Map knowledge base visibility
Knowledge base access is where portal scope most often drifts. The scope should state which articles are public to self-service users, which are restricted to technicians and which depend on the requester's entity or group. Agree the visibility rules as a matrix that lists each profile against each article category. Test the matrix with a sample user from each profile, not only with administrator accounts.
Define tiles for each organization
Tiles are the clickable blocks users see on the portal home page. The scope should list each tile, its target, its icon and the entity or group that sees it. Tailoring tiles per organization in a multi-entity setup needs a clear inheritance rule, so child entities do not show tiles meant for another business unit. Record that rule in the design document.
Plan reservation access
If the portal offers equipment reservations, the scope should state which assets are reservable, which profiles can book them and whether recurring bookings are allowed. Reservation behavior depends on how the asset types and their availability are configured, so confirm that setup against the GLPI version in your environment before build. Include a test for a booking that overlaps an existing one.
Receive configuration records and test results
Deliverables are written artifacts you keep after the engagement. Expect a configuration record that lists every changed setting, profile and tile, along with test results for each entry point and each visibility rule. Ask for the records in a format your team can store under change control, and confirm who owns the source of any templates or custom files.
Deliver into your infrastructure
All work is delivered into your own servers, virtual machines, containers or cloud accounts. The scope should name the staging and production environments, the access DeployOpen needs, and how changes move between them. Confirm where backups of the database and the configuration directory are stored before the portal goes live, because a portal change that breaks login affects every user.
Optional retainer after go-live
After go-live, portal changes usually continue as new tiles, new knowledge base categories and updates when GLPI releases a new version. These can be covered by a separate retainer for ongoing support, agreed in its own written scope. Ask what response arrangements the retainer covers, what is excluded and how plugin reactivation after a major update is handled.
