When GLPI change management needs its own implementation workstream
This page covers how to set up change management in GLPI once a team already runs tickets and asset records and now needs controlled changes to production systems. The short answer is that the change module is a separate body of configuration with its own analysis, planning and approval records, so it deserves its own scope, owner and acceptance criteria rather than being added as a side task to the helpdesk setup. According to the GLPI changes documentation, a change can be created in three ways: from a ticket, from a problem, or directly from Assistance > Changes. Each start point carries a different amount of context, which affects what the team must fill in before the change is useful to an approver.
Changes sit alongside tickets, problems and assets rather than replacing them. Tickets and problems can be attached to a change, and impacted items can be recorded against it, so the change record connects the request, the root cause and the affected configuration items in one place. That linkage is what makes the change module valuable, and it is also why it is usually scoped separately. The helpdesk workstream deals with service levels, routing and email intake, while the change workstream must agree on which assets count as impacted, who owns each item, and which tickets are allowed to trigger a change. Decisions on these points affect the helpdesk and the asset inventory, so they need a named owner before build work starts.
Before committing to a build, the implementing team should confirm three things with its own change authority: which start points will be permitted for production changes, which fields the analysis, deployment, backup and checklist sections must contain, and whether complex changes will be linked to projects, which the documentation says is supported. Confirm the notification behavior with your GLPI version as well, since changes use their own notifications. Ask any partner to show these choices in writing as part of a fixed scope, so that approvals, notifications and project links are tested against your real teams rather than a demonstration instance.
What the GLPI change module does out of the box
GLPI's change module ties a planned modification to the tickets, problems and assets it touches, and records how it will be assessed, deployed and reversed. The cards below cover the documented building blocks, with notes on what to confirm in the GLPI version you run before you design around them.
Creating changes from several entry points
A change can be raised from a ticket, from a problem, or directly from Assistance > Changes. The entry point matters for traceability: a change raised from a problem keeps the reason it exists, while a change raised from a ticket keeps the request that prompted it. Confirm which entry points your version exposes to each profile, since rights decide who can create changes at all.
Linking tickets and impacted items
Tickets and impacted items can be attached to a change, so reviewers see which requests and configuration items are affected before approval. Agree early which asset types must be linked for a change to be considered complete. Test the link on a sample change to confirm that the impacted items displayed match the inventory your team actually maintains.
Analysis of impacts and controls
The analysis phase is where the impact and the controls are written down: what breaks if the change fails, and what limits the damage. Keep this text specific enough that a reviewer can challenge it. Confirm with your own change policy whether analysis is mandatory for every change type or only for high-risk ones, because GLPI records what you enter but does not decide the risk level for you.
Deployment, backup plan and checklist
Each change carries a deployment plan, a backup plan and a checklist, so the steps to apply and the steps to roll back sit with the request itself. Ask your operations team to write the rollback path here, not in a separate document, so it is available during an incident. Verify in your version how checklist items are tracked and whether they can be marked complete by the assigned technician.
Linking complex changes to projects
Complex changes can be linked to one or more projects, which suits multi-stage migrations or platform upgrades that span several teams. Use project links for work that needs its own schedule and costs, and keep routine changes out of projects to avoid noise. Confirm how project status and change status are kept in step in your version, since the two records do not necessarily update each other.
Change-specific notifications
Changes use their own notification templates, separate from ticket notifications, so approvers and implementers can be informed without flooding the helpdesk queue. Map each event, such as a new change or a status update, to the recipients who need it. Test notifications with a non-production mail relay first and confirm the templates your version ships before you copy them.
Configuration decisions to settle before building change workflows
GLPI lets a change begin from a ticket, from a problem, or directly under Assistance > Changes. The entry point decides who creates changes and how much context they arrive with, so settle it before anyone is trained on the form.
- Ticket-first intake: Service desk staff raise a change from a ticket when a user request needs infrastructure work. This fits a small team where the desk already triages every request and the same people run both queues.
- Problem-driven changes: A change raised from a problem keeps the fix traceable to its root cause. Teams that already run problem management and need that link for audit evidence usually standardize on this path.
- Direct creation: Engineers create changes under Assistance > Changes. A regulated board can accept this path only if every direct change still passes a scope review, which usually means restricting the create right to a small group.
- Mandatory ticket rule: Decide whether a ticket or problem must exist before a change is allowed, and whether that rule is enforced by configuration or by convention.
- Profile rights per path: Map which profiles can create, edit and close changes on each entry point, and document the mapping.
Before building, confirm the create rights for each profile and test one change through every entry point so the board can see the trail each one leaves.
A change can carry impacted items, the assets and other records it is expected to affect. How broadly a team defines these items determines whether the analysis, notifications and approvals reflect real exposure or only the server being patched.
- Directly affected assets only: The change lists the hosts, network devices or applications it modifies. This is quick to maintain and suits a small team with a flat estate.
- Dependent services included: The change also lists the services and business applications that depend on those assets. A regulated board usually needs this so reviewers can judge customer and downstream impact.
- Attached tickets: Decide whether affected user tickets should be attached to the change so that service desk staff can answer questions during the window.
- Ownership of the list: Decide who completes impacted items, the requester or the technical owner, and whether the list is checked before approval.
- Dependency source: If dependency data lives outside GLPI, decide how it is kept current and who confirms it before a change is scheduled. Related modeling work is covered in the impact analysis topic.
Before configuring, agree the minimum set of impacted item types per change category and confirm that the list is reviewed before the change reaches the approval step.
The analysis phase of a GLPI change records impacts and controls, and the change also holds a deployment plan, a backup plan and a checklist. Templating these sections keeps records consistent, but a template that is too heavy leads people to paste boilerplate, which reviewers learn to ignore.
- Short standard text for small teams: A small team may keep one brief template with a deployment step list, a rollback sentence and a checklist of verification steps. This keeps the effort low and makes changes quick to close.
- Category-specific templates for regulated boards: A board usually needs different mandatory content for standard, normal and emergency changes, including explicit rollback criteria and evidence that backups were taken and tested.
- Backup plan wording: Decide what a backup plan must name, such as the system, the backup set, the restore test and the person who confirms it.
- Template ownership: Assign an owner for each template and a review date, so the text follows the environment rather than the first person who wrote it.
- Project links for complex work: Complex changes can link to one or more projects. Decide which change categories must link to a project and which only need the plan.
Before building, draft one template per change category, have a technical reviewer and an auditor read them, and confirm which fields the workflow must enforce.
Approvals in GLPI can be organized by group, so a change goes to the people responsible for the affected service rather than to a single manager. The group design determines how quickly changes move and how well the decision trail stands up to review.
- Single technical group: A small team may route every change to one group of senior engineers. This is fast and simple, but it puts all risk judgments with the same few people.
- Service-based approver groups: A larger organization can create groups per service or platform, so the owners who know the impacts approve their own changes.
- Board for high-risk changes: A regulated board usually adds a central group that reviews changes above a risk threshold and meets to decide. Define the threshold and who sets it.
- Membership and delegation: Decide how approvers are added, removed and replaced during leave, and whether a delegate can approve on someone's behalf.
- Evidence retention: Decide where approval comments are kept and how long they are retained, since auditors will ask for the record of who approved what and when.
Before configuring, map each change category to its approver group, confirm the approval steps and delegation behavior in your GLPI version, and test a full approval path with real group members.
Changes use their own notifications in GLPI, separate from ticket notifications. The recipients and events you choose decide whether owners act on time or learn about a change after it has started.
- Small team recipients: Notify the assignee, the requester and the technical lead at submission and at closure. This keeps traffic low and works when the same people see every change.
- Board and owner notifications: A regulated board usually wants notices to the board, service owners and the operations on-call group at submission, approval, start and closure.
- Group recipients: Decide whether notifications go to individuals, to groups, or to both, and confirm that group membership changes flow through to the recipient list.
- Event selection: Decide which events matter for each category. Too many events create noise that people filter out, which defeats the purpose.
- Templates and language: Decide who owns the notification text and whether it includes the impacted items, the window and the rollback contact.
Before configuring, write a recipient matrix of change category against event, check it with each owner group, and send a test change through the full lifecycle to confirm that each intended person receives the message.
How a change management build sequences in GLPI
The sequence moves from confirming the platform and access model to a piloted change process, so each configuration step rests on decisions that are already signed off. Each step closes with a named output that the next step depends on.
Confirm GLPI version and profile model
Confirm the GLPI version you will run and the profiles that will raise, analyze, approve and close changes. Check the version against the current release notes and the prerequisites in the installation documentation, since the platform version determines the available interface and upgrade path. Your GLPI administrator and the change manager agree which profile rights each role needs. Output: a written version decision and a profile matrix that lists who can create, analyze, approve and close changes.
Define change types and approval groups
Work with the change manager to define the change categories your organization uses, such as standard, normal and emergency, and state what each one requires before work starts. Map each category to the GLPI groups that approve it, including who can approve on behalf of a group. Confirm the rules with the CAB members who will use them. Output: a signed-off approval matrix that names each category, its approver groups and its required analysis fields.
Model impacted asset types on the existing inventory
Review which asset types and items the changes will touch, using the inventory already held in GLPI. Check that servers, network equipment, applications and other items are recorded consistently, because impacted items are only useful if they point to accurate records. Decide which item types should be attached to a change and whether any asset types must be added first. Output: a list of impacted item types and a short data-quality note listing gaps to close before go-live.
Configure analysis and plan templates
Set up the analysis fields that describe impacts and controls, and the deployment plan, backup plan and checklist that each change carries. Write the template text with the engineering and operations leads so that reviewers can judge risk without asking for extra detail. Keep templates short enough that standard changes can use them without friction. Output: tested templates, reviewed by a technical owner and a CAB member, with an example change showing every section filled in.
Add business rules for changes
Write the business rules that set defaults and enforce required fields, such as assigning an approval group from the category or requiring a backup plan for normal changes. Test each rule against sample changes in a non-production instance, including the edge cases where a change moves between categories. Record each rule with its purpose and owner so that later edits are reviewed. Output: a rule list with test results showing the expected outcome for each case.
Link projects and set change notifications
Decide which complex changes must link to one or more projects, and document who creates that link and when. Configure the change notifications so that requesters, approvers, assignees and affected groups receive the messages they need at each status. Check that the notification recipients match the approval matrix and that no group is left out. Output: a tested notification set and a written project-linking rule, both confirmed by the change manager.
Pilot with real changes and review
Run the process on a limited set of real upcoming changes, covering at least one standard and one normal change, and track where requesters, approvers or implementers stop or work around the process. Compare the records against the approval matrix and the impacted items list. Adjust templates, rules and notifications based on what the pilot shows, then confirm the change in writing before wider use. Output: a pilot review record listing findings, the fixes made and the sign-off to roll out.
Preparing asset data and existing change records
Change impact is only as accurate as the impacted items attached to each change, so asset inventory quality has to be settled before any change workflow goes live. A change that lists the wrong servers, applications or network devices will produce an analysis that looks complete and is wrong. Before loading anything, decide which asset types will be impacted by changes (computers, servers, network equipment, software, and any custom asset definitions your team uses), who owns the accuracy of each type, and how duplicates from earlier discovery runs will be merged. Install and verify GLPI Agent on the endpoints and servers that matter first, then compare the inventory it reports against your configuration management database or spreadsheet. Discrepancies at this stage are cheaper to resolve than in the middle of a production change window.
Historic change records usually sit in spreadsheets or in a previous ITSM tool. Map each source field to a GLPI change field (title, description, status, dates, requester, assigned group and impacted items) and to the analysis, deployment plan, backup plan and checklist sections, which are separate fields in GLPI. Records with free-text impact notes can be kept as archived text in the description rather than forced into structured fields. Decide early whether historic changes need links to the assets they touched, because that linkage is what makes later impact searches useful, and whether closed records are loaded at all. Confirm with the vendor or your own test instance which import route your target GLPI version supports, whether that is a documented import tool, the API or a controlled database load, and what it does with relations, dates and attached files. Do not assume a route works until a sample of records has been loaded, reviewed and reconciled against the source.
What drives change management effort and how to keep it down
This table lists the main factors that raise or lower the effort of a GLPI change management build, with how each one adds cost and how to reduce it. No effort figures were supplied for this topic, so ask for estimates against a written scope that names each driver's value for your organization.
| Driver | How it raises effort | How to keep it down |
|---|---|---|
| Number of approval groups | Each group needs its own approval workflow, membership rules, notification targets and test cases, and overlapping groups create routing conflicts. | Consolidate approvers into a small number of groups with clear scope, and confirm which approvals are truly required for each change type. |
| Depth of impacted-item modeling | Linking changes to every affected asset, software item and service multiplies data entry and validation, and deeper links depend on how complete the inventory already is. | Start with the asset types that drive real approval decisions, and extend the model later once inventory data is reliable. |
| Count of change types | Each change type can carry its own analysis, deployment, backup and checklist templates, and each template needs review and testing. | Limit change types to the categories that trigger different controls, and reuse templates across types where the steps match. |
| Integration with CAB reporting | Exporting change data to CAB packs, dashboards or external reporting tools adds mapping, format decisions and ongoing maintenance. | Agree the CAB report fields before build, and use GLPI's own views and saved searches where they meet the need. |
| Existing process documentation | Undocumented or inconsistent practice means decisions must be made during the build, which extends workshops and rework. | Provide current change procedures, roles and approval rules before scoping, and mark gaps the business must decide. |
| Number of entities | Each entity can need separate approval rules, visibility and notifications, and tests must cover how rights and data separate between them. | Use shared configuration where entities follow the same process, and limit entity-specific rules to documented differences. |
| Business rules for changes | Custom rules for urgency, risk scoring or automatic routing add conditions that must be tested against every change type and group. | Keep rules few and readable, and write down the expected result of each rule before building it. |
| Links to projects and notifications | Connecting complex changes to projects and setting change-specific notifications adds configuration and test scenarios for each path. | Limit project links to changes that need them, and confirm the notification recipients and events in writing. |
| User training and adoption | Technicians, approvers and requesters each need guidance, and inconsistent use after go-live generates support work. | Build short role-based guides from the agreed workflow and train approvers on the decisions they make, not on every screen. |
How change management connects to tickets, assets, projects and outside tools
Can a GLPI change be raised from an incident or a problem?
Yes. A change can be created from a ticket or a problem, or directly from Assistance > Changes when no ticket exists. The GLPI changes documentation describes this entry paths, so the change keeps a record of why it was raised. Confirm in your own instance which roles can create changes from tickets and problems, because those rights are set in profiles and can differ from the rights used to create changes directly. Agree early whether a problem record or a ticket is the single origin for a change, so reporting on root causes stays consistent.
How do impacted assets from inventory get attached to a change?
Each change can have impacted items attached, which are normally the assets, software or other configuration records the change touches. Those links are only as good as the inventory behind them. If hardware and software records come from GLPI Agent or a discovery process, the impacted list reflects what was last inventoried, not what is running now. Ask your team to confirm how often inventory runs for the affected asset types, and who owns the review of stale records before a change is approved. Impact analysis across dependencies is a separate design topic, so check whether your model needs more than direct links.
When should a complex change be linked to a GLPI project?
Link a change to a project when the change is one step in a larger body of work, such as a platform migration that spans several releases. According to the GLPI documentation, complex changes can be linked to one or more projects. This keeps the change approvals and deployment records separate from the project plan, costs and tasks. Keep the change as the control point for each production deployment, and use the project for scheduling, resourcing and budget. Confirm with your project office whether one project per change or one project for many changes fits how they report progress.
Which change notifications does GLPI send, and who receives them?
Changes use their own notifications, separate from ticket notifications, so approvers and implementers can be informed without flooding the helpdesk queue. The exact events, templates and recipients depend on your notification configuration and the groups or users attached to each change. Test every notification with a sample change in a non-production instance before go-live. Confirm who is responsible for mail delivery settings and whether the notification queue is processed on schedule, since a stalled queue means approvers never see their requests.
Can GLPI send change events to outside tools through webhooks or the API?
GLPI provides an OAuth2 API and documents outbound webhook integrations, so change data can be read or pushed to other systems. Whether a given change event can be sent to a particular tool depends on the webhook or plugin you deploy, so confirm the supported events and payload fields for your GLPI version before designing around them. Define which system is the record of truth for approval status, and make the receiving tool handle retries and duplicate events. Keep API credentials and webhook secrets under your secret management process, and restrict the API client to the change objects it needs.
How do identity, monitoring and device tools affect change data?
They change what data a change depends on, and what happens when that data is wrong. Directory sync decides who appears as an approver or implementer, so a user removed from a group can silently drop out of an approval path. Monitoring alerts may open tickets or problems that feed a change, and device management tools update the inventory that defines impacted items. Each connection needs an owner and a check: confirm group membership sync from your identity source, confirm alert-to-ticket routing, and confirm the frequency of device inventory. Mismatches usually appear as changes with no approver or assets that no longer exist.
Which connections must be confirmed before go-live?
Confirm the connections your change process depends on, then test each one with real records in a staging copy of your instance. The list usually includes:
- Ticket and problem links, including who can create changes from them
- Inventory sources for impacted items and how often they update
- Approval groups as synchronized from your directory service
- Change notification delivery and queue processing
- Any webhook, API client or plugin that sends change events out
- Monitoring and alert routing that opens tickets or problems
Ask the implementation partner or your own team to document the owner and test result for each item.
Can our own team build these connections, or should we use a partner?
Your team can build them if it has GLPI administration skills, access to the directory, monitoring and inventory systems, and time to test each path. A partner adds value when several systems must be connected at once, or when auditors will examine how change records are produced. Most engagements are fixed-scope, so the written scope should name each integration, its test cases and the deliverables. Ask for a quote based on the connections in scope, the number of approval groups and the reporting you need. Ongoing changes to the integrations can be covered by a retainer, which should be stated in the agreement.
Where GLPI change setups usually break
The most common failure is impacted items that drift out of date. A change record is only as useful as the list of assets and services attached to it, and in a GLPI instance where inventory updates arrive from agents while change owners edit records by hand, the attached items often describe the estate as it was months earlier. Check this during build by sampling a set of recent changes against the live inventory and confirming that the servers, applications and network devices named in each analysis still exist and still belong to the service shown. The second common failure sits in approvals. An approval step routed to a group with no active members either stalls silently or gets bypassed by someone with broader rights, so every approval group needs a named owner, at least two members for cover, and a periodic review tied to staff changes.
Business rules for changes are the next risk. Rules that set defaults, urgency or approval routing are evaluated against the entity of the change, so a rule written for one entity can fail to apply, or apply to the wrong requesters, when the change is raised by a user in a child entity whose visibility is restricted. Test each rule with a change raised by a user from every entity that will create changes, and confirm which profiles can see the resulting approval requests. Notifications fail in a quieter way. Teams configure change notifications, then discover that the recipients are the wrong group or that approvers receive mail they filter out, so the first real change should confirm delivery to each role and the approvers should say whether the message contains what they need to decide.
Finally, changes are often raised outside the process, for example as a ticket that a technician converts informally or as a project task that carries the deployment work with no change record. Testing with real change records and a pilot group catches these early. Ask a small group of operations staff to run three or four genuine upcoming changes through the full workflow, including the analysis, backup plan, checklist and approval, and record every point where they worked around the tool. This pilot usually exposes the stale items, empty groups and entity mismatches above within one change cycle, before the process is rolled out to everyone who can raise a change.
Questions buyers ask before bringing in a partner for GLPI change management
What does a GLPI change management engagement cost and what drives the price?
The price follows from the written scope, and DeployOpen does not publish a price list. The main cost components are the discovery of your current change process, the configuration of change templates, approval groups, business rules and notifications, the migration or validation of sample changes, and training for change managers and approvers. Some of this is one-time work. Hosting, licensing and internal review time recur. Costs rise with the number of change types, approval levels, integrations with project or CMDB data, and the number of teams that need their own rules. To compare quotes, ask each provider to list these components separately and to state which ones are fixed and which depend on your answers during discovery.
How long does GLPI change management setup take?
Duration depends mainly on how far your change process is defined before the build starts. A team that already has written change categories, risk criteria, approval rules and a CAB charter can move into configuration quickly. A team that has never agreed on these will spend most of the time in workshops. Other drivers are the number of approval groups, whether changes must link to projects or problems, how many notification recipients you need, and how many test cycles your change managers want before go-live. Ask for a schedule with discovery, build, test and rollout phases, and check that each phase has a named client owner and an agreed exit criterion.
What must our internal team provide for a change management project?
Your team needs to supply decisions and access, not only time. The most important inputs are a process owner who can settle disputes about change categories, approvers for each approval group with their delegation rules, and a set of real past changes with their deployment, backup and rollback plans so the templates reflect how you work. You also need access to the current GLPI inventory, including the assets and software records that impacted items will point to, and a test instance where configuration can be trialed. Ask the partner to list these inputs in the statement of work so gaps show up before the schedule slips.
Can our team configure GLPI change management alone using the documentation?
Yes, many teams do, provided they have someone with GLPI administration experience and a clear process design. The GLPI changes documentation describes how a change is created from a ticket or problem or from Assistance > Changes, how tickets and impacted items are attached, and how the analysis, deployment plan, backup plan and checklist are recorded. The harder work is designing business rules, approval logic and notifications so they match your policy, and testing them against edge cases. If your change process is unusual, or several entities need different rules, an outside review of the design before rollout often prevents rework. Your team should decide which part it can own.
How do GLPI upgrades affect our change management configuration?
Upgrades change the platform underneath your configuration, so plan for regression testing at each version move. The GLPI update procedure requires a backup of the database, the files and the config directory, including glpi.key and glpicrypt.key, followed by replacing the application files and running php bin/console db:update. Since GLPI 11.0, plugins are suspended when a new version is detected and must be reactivated after major updates. Change templates, business rules and notification settings should be exported or documented before an upgrade, then checked on a staging copy. Ask any partner how they will verify approval routing and notifications after each upgrade, not only that the application starts.
What should a quote for GLPI change management include?
A useful quote lists the scope in terms you can check. It should name the change types and workflows in scope, the approval groups and business rules to be built, the notification events, any project or problem links, and whether custom or plugin work is included. It should state the deliverables, such as configuration documentation, a test record and training sessions, and the acceptance criteria for each. It should show the one-time and recurring costs separately, list what your team must provide with dates, and say what happens if discovery reveals a larger process than expected. Ask how upgrades and post-go-live changes are priced. Because most engagements are fixed-scope, agree the written scope before work begins.
Which GLPI versions should we plan for when designing change management?
Plan for the version you will run for the next several years, not only the one you install today. The GLPI releases page lists GLPI 11.0.0 on October 1, 2025, GLPI 11.0.11 on October 1, 2026 and GLPI 12.0.0 on October 7, 2026. The GLPI 12.0.0 release notes describe a rewritten knowledge base, session management and step-up authentication for certain administrative actions, which can affect how administrators work with changes. Confirm the supported PHP and database versions for your target release against the GLPI installation documentation before you choose a host, and decide early whether you will use the official Docker image or a Linux install.
How DeployOpen scopes and delivers GLPI change management
DeployOpen plans, implements, customizes, documents and supports self-hosted open-source platforms inside your own infrastructure, including GLPI. For change management, we work from a written scope that defines how changes, impacted items, approvals, plans and notifications will behave in your instance before any configuration begins.
How we scope
- Confirm which change types, categories and entry points (tickets, problems, or Assistance > Changes) your process needs.
- Map approval groups, approval order and the roles that own each analysis, deployment plan and backup plan.
- Agree in writing which business rules, notifications and project links are in scope, and which are left to your team.
How we build
- Configure change templates, checklists and analysis fields so each change records impacts, controls and deployment steps consistently.
- Build and test business rules for changes and approval routing against sample changes in a non-production GLPI instance.
- Verify change notifications, links to impacted items and project links with test users in each group before go-live.
How we hand over
- Deliver written configuration records covering groups, rules, notification settings, templates and the approval matrix.
- Walk your change managers and technicians through raising, analyzing, approving and closing a change in your instance.
- Document the procedures your team needs to maintain rules and templates after handover, including how to test changes safely.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after the initial scope is delivered.
- Plan rule and template changes alongside GLPI upgrades, including the plugin reactivation steps required after major updates.
- Review approval and notification behavior with your team when your change process or organization structure changes.
