GLPI customization services

What GLPI customization involves

Customization in GLPI means configuring the platform's built-in mechanisms so the service desk and asset team work the way they actually operate. The main levers are entities and profiles for separating organizational units and access, business rules for automatic ticket and asset handling, ticket templates and forms for consistent intake, notifications for who hears about what and when, dropdowns and custom fields for the vocabulary your teams use, and marketplace plugins where the core does not reach. Most of this is done through the administration interface, and the design choices are yours to make before any plugin is considered.

Four situations usually trigger this work: a new service desk design, a move from another tool, new teams or sites joining the platform, or a requirement that default behavior cannot meet. The first three change the structure, such as how entities are split or which profiles exist. The fourth often points to a rule, a form or a plugin. Ask early which of these applies, because it determines whether the work is mostly configuration or whether a custom component is genuinely needed.

Small teams with one entity and a short list of ticket categories often configure the basics in-house, and that is a reasonable choice when someone on the team has time to learn the rule engine and test changes carefully. Partners are more often brought in when the design spans many entities, when business rules become intricate and interact with each other, or when a custom plugin must survive future GLPI upgrades. Ask any partner to show how they would scope those items, and confirm which parts of the work your own staff would own afterward.

Record every configuration decision. Keep a current document listing entities, profiles and their rights, rule order and purpose, template and form contents, notification recipients, and every plugin with its version and any local changes. Without that record, a GLPI upgrade becomes guesswork about what must still work. With it, you can rebuild the same behavior on a staging copy and test the upgrade against your actual design rather than the defaults.

What the work includes

Customization covers the parts of GLPI your service desk touches every day, from who can see which tickets to how requests arrive and who gets notified. Each area below is scoped in writing, and deliverables are agreed in writing in a fixed-scope engagement.

Entity and profile design

Map your organization into GLPI entities, then decide which profiles can see and act on which entities. Recursive visibility decides whether a parent entity's staff see child entity tickets, so it needs a deliberate choice per profile. Check each profile's rights against a list of real support roles before go-live.

Business rules for tickets, assets and imports

Business rules set default values, assign categories, fill fields and correct data as tickets, assets and imports are processed. Each rule changes live records, so rule order, conditions and criteria for imported data must be documented and tested against sample records before they run in production.

Ticket templates and categories

Templates pre-fill the fields, actions and checklists for recurring request types, while the category tree defines how tickets are classified and reported. Agree the category list with the teams who resolve tickets, because changes to it later affect reporting history and SLA assignment.

Forms and intake

Service catalog forms collect structured information from requesters before a ticket is created, which reduces back-and-forth with the service desk. Decide which fields are mandatory, which answers route the ticket, and how the form behaves for requesters in different entities.

Notification templates and recipients

Notification templates define the wording and content of emails sent for ticket events, and recipient rules decide who receives them. Confirm the mail collector and outgoing mail settings first, then test each event with a sample requester, technician and group to avoid over-notifying staff.

Dropdowns and custom fields

Dropdowns and custom fields extend the data model for your assets, tickets and contracts without changing the core application. Define field types, allowed values and who may edit them, since removing or renaming a value later can break existing reports and rules.

Marketplace plugin selection and configuration

Marketplace plugins add functions such as extra reporting, authentication or integrations. Select plugins against a written requirement, check their compatibility with the GLPI version you run, and record their configuration, because GLPI 11 suspends plugins after a new version is detected and they must be reactivated after major updates.

Custom plugin development where justified

A custom plugin is worth building only when a required behavior cannot be met with configuration or a maintained marketplace plugin. Expect it to carry its own upgrade, testing and support obligations for every future GLPI release, so the business case should be written before the build starts.

Configuration specification

The configuration specification records every entity, profile, rule, template, form, notification, dropdown and plugin setting, with the reason for each decision. It is the reference your administrators use after handover and the baseline for future upgrades.

Test case set

The test case set lists the scenarios each customization must pass, including visibility across entities, rule outcomes, notification recipients and plugin behavior. Run it again after every GLPI upgrade or plugin update to catch regressions before users do.

Change log and handover notes

The change log records each configuration change with its date, owner and reason, and the handover notes explain how administrators operate, back up and extend the customizations. Together they let your team maintain the platform without depending on the original builders.

What drives cost and duration

This table lists the GLPI customization factors that most change effort and schedule, why each one matters and how to keep it under control in the written scope.

Driver	Why it matters	How to keep it under control
Entities and profiles	Each entity and profile multiplies configuration, access testing and review work.	Model entities on real organizational boundaries and keep the profile list short.
Business rules	Each rule on tickets, assets or imports needs design, testing and a change record.	Agree a written rule list before the build and rank rules by business value.
Ticket types and intake forms	Each form adds fields, routing logic and reporting needs across categories.	Start with the most common request types and add remaining forms in later phases.
Notification flows and recipients	Recipient logic based on groups, locations or roles is difficult to test completely.	Limit notifications to events teams act on and document each recipient rule.
External integrations	Directory, email, monitoring, ordering and finance systems each need credentials, field mapping and failure handling.	Confirm interfaces and system owners first, then build and test one integration at a time.
Marketplace plugins	Each plugin adds an upgrade dependency and may change behavior or data after a GLPI update.	Check maintenance activity and confirm compatibility with the target version before selecting it.
Custom plugin	Custom code must be maintained through every GLPI upgrade and security patch.	Build a custom plugin only when configuration and existing plugins cannot meet the requirement.
Target version	GLPI 12.0.0 (October 7, 2026) and 11.0.0 (October 1, 2025) differ in prerequisites and plugin handling.	Confirm plugin compatibility and PHP and database prerequisites before fixing the version.
Environments and acceptance testing	Test and staging copies add setup work, and each user acceptance round adds review time.	Agree the number of environments and acceptance test cycles in the written scope.

Project phases and outputs

The sequence moves from understanding how your service desk works today to a tested, documented GLPI configuration that your team can run and change after go-live.

Discover current service desk processes
We interview service desk leads, technicians, requesters and asset owners to map how tickets are raised, routed, approved and closed today, and who holds each role. The output is a process and role inventory that lists which customizations solve real problems and which ones are requests for change without a clear owner. The step is complete when the process owners have confirmed the inventory in writing.
Write the design specification
We turn the inventory into a written specification covering entities, profiles, groups, business rules, ticket templates, forms, dropdowns, custom fields and notifications, with each item tied to a process it supports. The specification also records what stays in standard GLPI and what would need a marketplace plugin or custom code. It is done when your stakeholders have signed off the document and the open decisions are closed or assigned.
Build on a staging copy
We implement the specified configuration on a staging instance that mirrors your production GLPI version, plugins and authentication setup. Changes are made through the GLPI interface or versioned configuration exports where possible, so each change can be traced back to a specification item. The output is a staging environment and a change log that maps every configured object to its requirement.
Test with pilot users against scenarios
Pilot technicians and requesters run a written set of scenarios, such as a request from each entity, an escalation, an approval, a rejected form and a ticket that hits an SLA or notification boundary. Each result is recorded as expected or defective, and defects are fixed on staging and retested. The step closes when every scenario has a passing result, and the open defects are either fixed or accepted by the process owner.
Release to production and hand over
We apply the tested changes to production in a planned window, verify the same scenarios on production data with test records, and confirm that profiles and entity access match the specification. Administrators receive the configuration documentation, the change log, a runbook for routine changes and a short training session. The handover is complete when your administrators have made a supervised change themselves.
Review rule behavior and notifications
After go-live we review how business rules, assignment logic and notifications behave with real volumes, looking for unexpected reassignments, duplicate or missing emails and forms that users complete incorrectly. Findings are logged against the specification, and corrections go through the same staging and test path. The review closes with a written list of changes made, changes deferred and ownership of ongoing rule maintenance.

What stays in-house and what goes to a partner

This table compares, for each GLPI customization work area, what your own team usually keeps, what a partner usually takes on, and the skills each side needs.

Work area	Usually kept in-house	Usually outsourced	Skills required
Process ownership and approvals	Deciding ticket categories, approval paths, SLA intent and who signs off each change to the service desk rules	Documenting current workflows, drafting the specification and running workshops to turn decisions into a written design	Service desk process knowledge, ITIL-style change control, GLPI administration to confirm what each setting does
Day-to-day rule and template editing	Adjusting ticket templates, dropdown values and routine business rule tweaks once the design is stable	Initial build of templates and rules, plus training for the admins who will maintain them	GLPI administration, basic understanding of the rules engine and template variables, database checks when rules misbehave
Entity and profile design	Naming entities, choosing which groups and teams see which tickets and assets, and approving access changes	Modeling the entity tree, profile rights and assignment rules, then testing them against real user accounts	GLPI administration of entities, profiles and rights, LDAP group mapping where used, access review practice
Complex rule chains	Owning the business logic and reviewing rule order and outcomes before each release	Building multi-step rule chains, reducing overlap between rules and documenting the execution order	GLPI rules engine expertise, PHP for custom criteria or actions where core rules fall short, SQL to trace rule effects
Notification logic	Defining who must be told about which event and approving the message wording and recipients	Configuring notification targets, templates and event triggers, then checking delivery through the mail setup	GLPI notification administration, mail server and SMTP troubleshooting, Twig-style template editing in GLPI
Plugin selection	Setting selection criteria, approving license terms and deciding which plugins are supported long term	Reviewing candidate marketplace plugins for compatibility, security posture and maintenance activity against your GLPI version	GLPI plugin architecture knowledge, PHP code review, awareness of GLPI version compatibility
Custom plugin development	Defining the requirement, accepting the code and owning the backlog once the plugin is in production	Designing and coding the plugin, writing its install and uninstall logic and handing over source and tests	PHP development against GLPI's plugin API, database schema design in MariaDB or MySQL, secure coding and code review
Testing and handover	Running acceptance tests against written scenarios and signing off each release to production	Building a test plan, a staging copy of the database and files, and documentation for each rule, template and plugin	Staging environment management, database backup and restore, GLPI administration, writing reproducible test cases

What usually goes wrong

Most GLPI customization problems come from a small set of design choices made early and tested late. The cards below name each failure and the check that prevents it.

Business rules that conflict or fire out of order

GLPI business rules run in a defined order, and several rules acting on the same ticket can overwrite each other's fields without any error. Before go-live, list every active rule for tickets, assets and assignments, document its trigger and priority, and test a sample ticket that matches more than one rule to confirm the final state is what the service desk expects.

Entities and profiles that expose tickets

Entity and profile design controls which teams see which tickets and assets. A profile granted broad read rights on a parent entity can expose tickets from child entities that belong to other departments or clients. Test each profile with a non-administrative account in every entity, and confirm that recursive visibility is set only where it is intended.

Notification floods and missing recipients

Notification templates and targets decide who receives an email when a ticket changes state. Overly broad targets can flood shared mailboxes, while a target that resolves to no address silently drops the message. Review each notification event against its recipient rules, send test tickets through the production mail path, and check the mail queue for failed deliveries.

Dropdowns that fragment reporting

Dropdowns created ad hoc by different administrators often hold near-duplicate values such as similar category names or spelling variants. Each variant splits counts in reports, dashboards and SLA analysis. Agree a controlled list of categories, locations and statuses with the owners of reporting before creating fields, and assign one person to approve changes.

Marketplace plugins that no longer fit

Marketplace plugins vary in maintenance. Some have not kept pace with new GLPI versions, and an incompatible plugin can block an upgrade or behave incorrectly after one. For each plugin, check the publisher's last release, its declared GLPI version support, its license and its data footprint, and record the decision in your change log before adding it to production.

Custom plugins that break on upgrade

A custom plugin written against one GLPI release can depend on internal classes, hooks or database tables that change in the next. Since GLPI 11.0, plugins are suspended after a new version is detected and must be reactivated after major updates, so every plugin needs an upgrade test on a copy of production before the update window. Keep plugin code in version control and pin the GLPI versions it supports.

Changes made directly in production

Rules, dropdowns, forms and notification templates edited in the live interface leave no record of who changed what and cannot be rehearsed. Restore a recent database and file backup into a staging instance, apply each customization there first, and confirm the result with test users. Keep an export of the configuration so a production change can be reversed.

How the work changes by starting point

A fresh GLPI instance has no prior configuration to protect, so the work is mostly design: entity and profile structure, ticket categories, forms, notifications and the first set of dropdowns and custom fields are all defined from scratch. Customization can be sequenced cleanly, with each change tested before the next one is added.

Scope: design workshops on entities, profiles and ticket flows come first, then build and test.
Reused: the platform defaults, and any standard fields that already fit your process.
Risky: adding business rules and custom fields before the data model is agreed, which forces later rework of tickets and reports.
Confirm: which marketplace plugins your edition and GLPI version support before you depend on them.
Also check: the server build (document root, PHP and database versions) is set up correctly from the start, since that is harder to change later.

What you need to provide

Decisions and documents come first. Before build starts, name a process owner for the service desk who can sign off on ticket behavior. Provide the current ticket categories, the SLA and approval rules written down (even if they are informal today), the organization chart and the entity structure that GLPI should mirror. Those four items drive how entities, profiles, business rules and approval steps are configured. Without them, the build team will be making policy choices on your behalf.

Environment access on a staging copy. We need a staging GLPI instance with its database and configuration directory, not production. Include the list of marketplace plugins already in use and the exact version of each, because plugin compatibility determines what can be customized and what must be replaced. Ask your team to confirm the GLPI and PHP versions currently running, so the test environment matches production. Access to the glpi.key and config files is needed only under secure handling arrangements agreed in advance, and encryption keys should never travel by email or chat.

Test data under our data rules. A sample of real tickets and asset records helps verify templates, forms, dropdowns and business rules against the data people actually enter. Agree how that data is masked or minimized, where it is stored, and who can see it before it is exported. Provide SMTP details for notifications, including the sending address, relay host and whether the relay needs authentication, so notification rules can be tested end to end on staging.

Approval rules for future changes. Decide who approves changes to business rules, profiles and notification templates after go-live. Without a named approver for these objects, small changes accumulate, profile permissions drift and the configuration no longer matches the documented process. Confirm this in writing before handover, along with who may create custom fields and who maintains the dropdown lists.

Frequently asked questions

How much effort does GLPI customization take, and what drives it?

Effort depends mainly on how many service desk processes you are changing and whether the change can be met with GLPI's built-in features. Drivers include: the number of entities and profiles, how many business rules and ticket templates you need, whether forms and notifications must follow approval logic, and whether a marketplace plugin already covers the need. Each custom plugin, integration or data model change adds design, build, testing and upgrade work. Ask any partner for a written breakdown by item so you can compare scope, not totals.

Can our own GLPI administrators make these customizations?

Often yes for configuration work such as dropdowns, custom fields, notifications, ticket templates and many business rules, provided someone on your team understands GLPI profiles and documents each change. Custom code, plugin development and changes that touch the database or upgrade-sensitive files usually need a developer with PHP and GLPI plugin experience. Confirm your administrators' skills against the list of items in your scope before deciding what to hand off.

How long does GLPI customization take, and why does it vary?

Duration follows scope, not a fixed template. Configuration-only changes move faster than work that needs custom plugin code, new integrations or data migration, because those add design review, build and testing cycles. Your own approval speed, the number of stakeholders who sign off on ticket workflows, and the availability of a staging copy also change the timeline. A fixed-scope agreement should state the phases and milestones in writing before work starts, and you should ask for the assumptions behind each one.

Is a custom GLPI plugin worth building instead of using a marketplace plugin?

A custom plugin is worth considering when a requirement is specific to your processes, no marketplace plugin meets it, and the business value justifies ongoing maintenance. Check the marketplace first, then compare build cost against configuration options and the cost of changing your process. Ask who will maintain the plugin after go-live, how it will be tested against each new GLPI release, and what happens if the original developer leaves. Confirm current compatibility with the GLPI version you plan to run.

How do plugins affect GLPI upgrades?

Plugins are the most common source of upgrade surprises. The GLPI update procedure requires a backup of the database, files and config directory, including the glpi.key and glpicrypt.key files, followed by replacing application files and running php bin/console db:update. Since GLPI 11.0, plugins are suspended after a new version is detected and must be reactivated after major updates, so each plugin needs a compatibility check on a staging copy first. Ask who owns plugin compatibility testing before each upgrade.

How are GLPI customizations tested before they reach production?

Changes should be built and reviewed on a staging copy that mirrors your production GLPI version, plugins, database and key files, then tested against documented scenarios for each profile, entity, ticket template and notification. Test data should be realistic in shape but must not expose personal data to people who should not see it. Keep a rollback plan, record each change in a change log, and confirm with your partner exactly which tests are included in the fixed scope and which tests your team must run.

How DeployOpen delivers GLPI customization

DeployOpen plans, builds, documents and supports GLPI customizations inside infrastructure you control, so your service desk configuration stays under your team's ownership. Each engagement starts with a written scope that defines which customizations are in and out before any build work begins.

How we scope

The written scope lists the entities, profiles, ticket templates, forms, business rules and notifications covered by the engagement.
We map each proposed custom field, dropdown and rule to the service desk process it supports, so unnecessary configuration is caught early.
We record which needs are met by marketplace plugins and which would require a custom plugin, with the reasons for each decision.

How we build

We build and test changes on a staging copy of your GLPI instance before anything reaches production users.
Business rules, notifications and forms are tested against sample tickets for each profile, entity and requester group in scope.
Custom plugins, where agreed, are checked for compatibility with the GLPI version you run and with the plugins already installed.

How we hand over

You receive documentation of every configuration change, including the entity, profile and rule logic behind it.
Configuration exports, plugin versions and the test cases used during acceptance are delivered as part of the handover.
Your administrators are walked through daily configuration tasks so changes after go-live can be made by your own team.

How we support

Ongoing support, upgrades and testing are available as a retainer, and the scope of that retainer is agreed in writing.
Customizations are retested when GLPI or a plugin is upgraded, so plugin reactivation and rule behavior are checked before users see changes.
Ask your quote to name who maintains each customization after handover, and what the retainer covers for changes requested later.