How GLPI impact analysis maps what a failure touches
Many IT teams have accurate inventory in GLPI but still cannot say which business services stop when a rack, cluster or network device fails. GLPI impact analysis answers that question by drawing an infrastructure diagram of impacts (red arrows) and dependencies (blue arrows) that can be saved and exported. The tool itself is simple to switch on. The effort is mostly data modeling: deciding which items relate to which, and recording those relationships consistently enough that the diagram tells the truth during an incident. Teams usually start this work when they are already changing how they handle risk, which is why it is often scoped alongside change management and data center and rack modeling in GLPI.
Before building diagrams, confirm which asset types your team needs to model. According to the GLPI impact analysis configuration documentation, impact analysis can be enabled for appliances, clusters, computers, data centers, server rooms, domains, enclosures, monitors, network devices, PDUs, peripherals, phones, printers, racks, software and database instances, plus custom asset definitions. Enabling a type is a configuration decision, so decide it with the people who own service maps, not only with the GLPI administrator. Appliances and clusters are often the most useful starting points for business services, because a single cluster can carry several applications. Ask your GLPI partner or internal owner to document which types are enabled, which are deliberately left out and why, so later users do not wonder why a diagram looks incomplete.
The modeling work also has to be governed. Each relationship you record is a claim that someone must keep current when hardware moves, virtual machines are rebuilt or a service is retired. Assign an owner for each business service map, set a review cadence agreed with operations, and check diagrams against a real failure scenario, such as a planned power test or a rack maintenance window, before relying on them. The GLPI Help Center guide to impact analysis is the natural next read for the diagram itself. Plan the time for data cleanup as a distinct workstream, because dependency mapping quickly exposes duplicate, stale or unnamed records that must be fixed first.
What impact analysis does in GLPI
GLPI impact analysis combines two kinds of links into one picture of how assets support each other. The cards below describe the diagram, the asset types you can enable, custom definitions and how the diagram feeds change analysis, so you can decide what to model before anyone draws a line.
Impacts and dependencies diagram
The impact analysis view draws an infrastructure diagram with impacts shown as red arrows and dependencies as blue arrows. Each arrow reads in one direction, so the team must decide which item depends on which before drawing. Check that the arrow direction matches how your operators talk about failures, because a reversed link will show the wrong blast radius during a change review.
Saving and exporting the diagram
A diagram can be saved and exported, which lets you keep a dated copy of how services were mapped at a given point. Treat the saved view as a snapshot, not a live record, and agree who updates it when assets move. Confirm the export formats available in your GLPI version before promising a deliverable to an auditor or a service owner.
Asset types that can be enabled
Impact analysis can be enabled for appliances, clusters, computers, data centers, server rooms, domains, enclosures, monitors, network devices, PDUs, peripherals, phones, printers, racks, software and database instances. Enable only the types your service models need, because each enabled type adds nodes that someone must keep current. Start with the layers that carry your business services, such as clusters, network devices, racks and database instances.
Custom asset definitions
Impact analysis also covers custom asset definitions, so asset types GLPI does not ship can join the diagram. Decide early which custom types represent items that fail independently, since those are the ones worth modeling. Confirm with your GLPI administrator how custom definitions are enabled for impact analysis in your version, because the setup sits alongside the definition design.
Feeding change analysis
The diagram gives change reviewers a visual check of what a planned change could affect, which supports the impact analysis step in change management. Use it as an input to the change record, not a replacement for the approver's judgment. Check that the services named in the diagram match the impacted items attached to each change, or reviewers will see two different pictures of the same risk.
Impact versus dependency links and why the difference matters
In GLPI's impact analysis diagram, a red arrow shows an impact link and a blue arrow shows a dependency link. The distinction is about which way a failure travels. A dependency link says that one item relies on another to function, so the depended-on item is the one you check first when something breaks. An impact link says that a change or failure in one item can affect the item it points to, so it answers the question of what else is hurt if this goes down. Before you draw anything at scale, confirm the exact meaning and arrow direction for your GLPI version in the GLPI impact analysis documentation, because teams often read the arrows backwards on their first pass.
A simple rule helps when you model each pair of items. Ask whether the second item would stop working or degrade if the first one failed. If yes, record the relationship so the diagram shows the path a failure would take. Ask separately whether the first item needs the second one to run at all. These two questions often produce different answers. (Illustrative example) A database instance is hosted on a virtual host. If the virtual host fails, the database instance stops, so the failure reaches the database. The database instance depends on the host for its runtime. Recording the relationship in the direction your version documents lets an analyst start from the host and see the database and the application behind it. Build a short test diagram with two or three known items and walk through a simulated outage before you apply the pattern to the whole inventory.
The difference matters because the links feed impact analysis from the start of an incident or change. If a team links items in the wrong direction or uses one arrow type for both meanings, the diagram will show plausible paths that do not match reality, and someone may skip a dependent system during a maintenance window. Agree on a written convention covering which link type each asset pair uses, who approves new links, and how the team handles items shared across entities. Then review the exported diagram with the service owners who would be paged during an outage. Their feedback is the fastest check that the arrows express what operators actually experience.
Modeling business services with appliances, clusters and racks
An appliance in GLPI can represent a complete business service or product, such as a payment gateway, an HR portal or a document platform, rather than a single physical box. You attach the servers, databases, network devices and software that make the service work, then draw impact and dependency links from the appliance to the items it relies on. This fits services that are owned as a unit, have a named owner and are changed as a unit. It is less suitable where the same components serve many services, because the wrapper then hides shared dependencies.
- Service identity: The appliance record carries the service name, owner group and status, so change and incident records can point to one object.
- Component links: Attach the hosts, databases and software items the service needs, and record which of them is a dependency and which is an impact.
- Maintenance load: Every new component, migration or retirement needs a matching update to the appliance links, or the diagram drifts.
- Ownership: Someone must own each wrapper and review it at a set interval, usually at the same time as the service review.
- Duplication risk: Avoid creating a second appliance for the same service under a different name, since impact results then split across two records.
Before building wrappers, confirm with the service owners which components they consider part of the service and whether a single wrapper per service is the unit they will maintain.
A cluster record represents a group of hosts that share a failure domain, such as a hypervisor cluster, a database cluster or a container platform. Modeling the cluster lets you show that several services depend on the same group of nodes, so a failure or planned outage of the cluster appears as a shared impact instead of a set of unrelated host problems. Clusters fit well where the shared platform carries many services and where the platform team manages membership. They are less useful when membership changes often and nobody updates the records.
- Shared exposure: Linking a cluster to the services that run on it shows the blast radius of a platform outage at a glance.
- Membership accuracy: Node membership must match the platform's real state, which usually means reconciling with the hypervisor or orchestrator inventory.
- Layering: Pair the cluster with the hosts or virtual machines beneath it so that impact can be read at both levels.
- Recurring upkeep: Scaling out, replacing nodes or retiring a cluster all require record updates that the platform team should own.
- Clear boundaries: Decide whether a cluster is one fault domain or several, because the answer changes how impact should be read.
Confirm with the platform team whether they already track cluster membership in a source of truth you can synchronize from, since manual upkeep is the usual point of failure.
Data centers, server rooms, racks, PDUs and enclosures represent physical dependencies: power, cooling, network paths and floor location. Linking equipment to the rack, the PDU and the room lets impact analysis show that several servers share a power feed or a site, which matters for outages that never touch the software layer. This model fits organizations where physical events such as a power maintenance window or a facility move are real planning concerns. It fits less well where all workloads run in a public cloud, because the physical records then describe providers' facilities rather than your own.
- Power and site visibility: Connecting hosts to PDUs and racks exposes shared power and location dependencies.
- Data center records: Room and rack records give facilities and operations teams one place to see what sits where.
- Detail level: Decide how far down to go, since modeling every cable and port adds upkeep without always adding insight.
- Sync with reality: Rack moves and hardware swaps must be recorded when they happen, otherwise the physical view and the inventory disagree.
- Shared responsibility: Facilities teams and platform teams need to agree who updates which records.
Check whether your facilities or data center team already maintains rack and power data, because duplicating that work in GLPI is often the largest hidden cost of this model.
GLPI offers a broad set of built-in asset types for impact analysis, but some of your components may not match any of them, such as a separate class of server, a specialized appliance or a service-specific resource. Custom asset definitions let you create those types so they can take part in impact and dependency links like built-in types. Use them when a missing type would otherwise force you to misrepresent a component. Avoid them when a built-in type already fits, because every extra type adds configuration, permissions and reporting work.
- Fit test: Compare each candidate component against the built-in types first and record why none fits before creating a new one.
- Naming and rights: The type name becomes part of how APIs, webhooks and profiles refer to the asset, so decide naming before records are loaded.
- Schema maintenance: Custom fields and capacities need an owner who reviews them when the component changes.
- Upgrade impact: Check how custom types behave through GLPI version upgrades, and confirm this in your test environment before production.
- Limited reuse: A type used by one team may not justify the upkeep, so consider a shared wrapper instead.
When scoping this work, ask who will maintain the custom definitions after go-live and whether that owner is named in the operations plan.
Configuration decisions before the first link is drawn
This table compares six configuration decisions that shape GLPI impact analysis and CMDB dependency mapping, with the option, when it fits and the main risk of each. Read it before enabling asset types or drawing the first impact or dependency link, because most later rework traces back to one of these choices.
| Decision | Option and when it fits | Main risk |
|---|---|---|
| Which asset types to enable | Enable only the types that carry business services, such as appliances, clusters, computers, database instances, network devices and software. Add others once the first service map is reviewed. | Enabling every type clutters the diagram and makes reviewers stop trusting it. Missing types leave gaps in the chain. |
| How deep the impact chain goes | Stop at the service's hosting layer (for example, cluster to host to database instance) for a first version. Extend to network and power only where outages have been traced to those layers. | Very deep chains are slow to maintain and hard to read. Shallow chains hide the path from a failed rack or PDU to a business service. |
| Modeling business services as appliances or custom definitions | Use an existing appliance record when the service is a single product with its own inventory entry. Use a custom asset definition when the service is a logical grouping with no physical or software counterpart. | Appliance records force a physical meaning onto a logical service. Custom definitions need profile rights and naming agreed before data entry starts. |
| Who owns each relationship | Assign an owner per business service, usually the service owner, with infrastructure teams confirming the links they manage. Record the owner in a field or group that reviews can filter on. | Without named owners, links drift and nobody confirms them. Owners who never see the diagram will not spot errors. |
| How links stay current when inventory changes | Keep links maintained through a fixed review step tied to inventory updates, change records or a periodic check. Confirm with your team how GLPI Agent or import data will reflect new hosts. | Inventory updates can add or retire assets while impact links still point to old records, so outage paths look correct when they are not. |
| Whether the diagram is exported for reviews | Export the saved diagram for change advisory or service reviews when auditors or managers need a fixed record. Keep the live view for daily operational use. | An exported image goes stale as soon as the model changes. Reviewers may approve a path that no longer exists, so date and version each export. |
How the impact map is built in sequence
The sequence turns scattered asset records into a reviewed set of business service diagrams, with each step producing an artifact the next step depends on. Done in order, it gives you a map that service owners have checked and that stays current after the first build.
Confirm the GLPI version and asset types
Confirm which GLPI version you run, then open the impact analysis configuration and enable only the asset types your services need, such as appliances, clusters, computers, racks, network devices, databases or custom asset definitions. Check the version against the upgrade plan first, because asset definitions and plugin behavior can differ between releases. The output is a written list of enabled asset types, agreed by the GLPI administrator and the team that will maintain the map.
Agree the business services and owners
Work with business and service owners to list the services the map must describe, such as a customer portal or payroll run, and name one accountable owner for each. Keep the first list short and tied to business impact rather than to every system in the estate. The output is a register of services, owners and the business question each diagram must answer, such as which systems stop when a database fails.
Load or verify source inventory
Check that the assets behind each service already exist in GLPI with accurate names, types and locations. Source them from GLPI Agent inventory, spreadsheet imports or exports from an existing CMDB, and reconcile duplicates before modeling. Missing or duplicate records are the most common cause of incomplete diagrams, so this step is complete when each asset in scope has one record and a named owner. The output is a reconciled inventory extract for the in-scope services.
Model the top services first
Start with the one or two services with the highest business impact. For each, create impact and dependency links between the relevant items and review the generated diagram for gaps, such as a shared storage cluster that is missing a link. Use the impact relation for what is affected when an item fails and the dependency relation for what the item needs to run. The output is a saved diagram for each priority service and a short list of unresolved links.
Review diagrams with service owners
Walk each service owner through their diagram and ask them to confirm the components, the direction of each link and any missing external dependencies, such as a third-party API or a network路径 that sits outside GLPI. Record each correction as a change to the model rather than a comment on the diagram. The output is a signed-off diagram per service, with the owner's name and review date recorded in GLPI or your change record.
Export and store the reviewed maps
Save each approved diagram in GLPI and export it in the format your change and continuity documents use, so the reviewed state is preserved outside the live system. Confirm that the export contains the services, owners and links you reviewed. The output is a versioned set of exported diagrams and a note of which GLPI version and asset data they reflect.
Tie the map to change requests
Set a maintenance routine in which every change request affecting an in-scope asset requires a check of its impact and dependency links before approval. Assign a named owner for the routine and for updates to the service register when new services are added. The routine is in place when a sample change shows the impact check being completed and the diagram being updated after implementation. The output is a documented maintenance procedure linked to your change workflow.
Loading existing CMDB data into GLPI without inheriting its errors
Clean the source data before it reaches GLPI, because impact diagrams inherit every duplicate and stale record they are fed. An impact map is only as trustworthy as the asset items and links behind it. If a server appears twice under two names, or a decommissioned database instance still sits in a rack view, the diagram shows paths that do not exist and hides ones that do. Data arrives from three places in most organizations: spreadsheets exported by teams over several years, an existing CMDB or asset register, and inventory agents reporting from endpoints and servers. Each source has its own identifiers, naming habits and update cycle, so the first task is to decide which source is authoritative for each asset type and to agree on one key per asset, such as a serial number, a hostname with a domain, or an agent-reported unique identifier.
GLPI's migration and inventory tooling is where this data lands. The migration module imports spreadsheet and file-based data, and the GLPI Agent and inventory plugin keep computers, software and network devices current once they are connected. Run imports into a non-production instance first and check duplicates on the key you chose before anything is linked to a business service. Ask your implementation partner and your GLPI contact to confirm which import formats and matching rules apply to your GLPI version, since the migration and inventory workflows differ between the 10 and 11 releases. Once agents report into the same records, decide which source wins when they disagree, and write that rule down. Stale records need an owner and a retirement step, not just deletion, so that historical links to changes and incidents remain readable.
What drives the effort of a dependency map
This table lists the factors that expand or shrink the work of building a GLPI impact analysis map, with the effect of each and how to keep it contained. Read it before scoping, since the first three drivers usually decide whether the map takes a few focused sessions or a long validation cycle.
| Driver | How it raises effort | How to keep it down |
|---|---|---|
| Number of business services | Each service needs its own chain of appliances, clusters, software and database instances, and each chain must be checked against how the service actually runs. | Start with the three to five services with the highest outage cost, then extend the map in later phases. |
| Depth of dependency chains | Every extra hop (service to application to database instance to cluster to host) adds links to draw and verify, and errors compound along the chain. | Model only the layers that change impact decisions, and stop at the level where an owner can answer for the component. |
| Quality of existing inventory | Duplicate computers, unnamed software records and assets never linked to a location force cleanup before any dependency can be drawn. | Confirm inventory completeness for the in-scope services first, using agent data where it exists, and fix naming before drawing links. |
| Number of asset types enabled | Each enabled type (racks, PDUs, printers, phones and so on) adds a choice to test in the impact view and more fields that people must keep current. | Enable only the types that appear in business service chains, and document why any other type is left out. |
| Custom asset definitions | Custom types need their own profile rights, capacities and impact configuration, and they must be tested before the diagrams can rely on them. | Reuse existing types where they fit, and create a custom definition only when the service model needs a type GLPI does not ship. |
| Number of owners who must validate | Each owner reviews diagrams for their part of the chain, and disagreement about who runs a component can stop sign-off for weeks. | Assign one accountable owner per service, collect corrections in one review pass, and record the approval date in the map documentation. |
| Integration with change and monitoring data | Feeding impact data into change planning or alerting means agreeing field use, naming and update triggers with other teams, and testing each feed. | Define the minimum data the change process needs, and link monitoring to existing asset records rather than building a parallel model. |
How the impact map connects to change, inventory and monitoring
An impact map is only as current as the items and links behind it. The cards below cover the GLPI workstreams and external tools that feed the map, consume it, or need to stay in step with it, and what to confirm in your environment before you rely on the diagram.
Change management analysis
Impacted items recorded on a change are the input that change analysis reads when a planned update could disrupt a service. If the impact links are incomplete, the change reviewer sees a partial picture and approves work without knowing which business services sit downstream. Confirm which asset types your change workflow lists as impacted items, and who keeps those records accurate between changes.
Inventory and network discovery
Dependency diagrams go stale when hardware, virtual machines and network devices move without anyone editing GLPI. Automated inventory keeps the asset records that impact links point to current, but it does not create dependency links on its own. Confirm which discovery sources feed each asset type in your map and whether a person reviews new items before they join a business service.
Physical dependencies in data center management
Racks, power distribution units, enclosures and server rooms are where many hidden dependencies sit, such as two servers sharing one PDU. Modeling them lets the impact diagram show a power or cooling failure reaching the services above it. Confirm that the physical model matches what is installed, since a rack record that lags behind the floor gives a false sense of redundancy.
Custom asset definitions
Some dependencies involve components GLPI does not ship as asset types, such as a separate server model or a business application instance. A custom asset definition gives those items their own record and lets them take part in impact links. Confirm the names and fields with the teams that call the API or webhooks, because renaming a definition later can break those integrations.
Integrations and data export
Webhooks and the OAuth2 API let other systems read asset and relationship data, so the impact map can be exported to reporting, wikis or a monitoring dashboard. Each integration needs its own identity, scope and error handling. Confirm which fields leave GLPI, who may receive them, and how removed items are handled on the receiving side.
Monitoring tools in the wider platform
Monitoring systems detect that a host or service is failing, while GLPI shows what depends on it. Connecting the two lets an alert point to the business services and owners affected. Decide which system is the source of truth for host names and identifiers, and confirm that the names used in monitoring match those in GLPI before you build any link between them.
Questions teams ask before hiring help with impact analysis
What does impact analysis work cost, and what drives the price?
Cost depends on how many services you want to map, how many asset types they touch, and how much of the inventory is already reliable. Ask for a quote built from a written scope that lists the services, the asset classes, the number of review rounds and the handover material. Most of the cost is people time for discovery with service owners and for checking links against the real environment. Licensing is a separate question: GLPI itself is open source under the GNU General Public License version 3, so the platform carries no license fee, while any GLPI Network subscription is priced by the vendor (for example, the self-hosted tiers listed on the GLPI Network subscriptions page run from 100 euros per month for Basic). Ask whether your quote includes ongoing map upkeep, which recurs, or only the initial build, which is one-time.
How long does a dependency map take to build in GLPI?
Duration depends mostly on inventory quality. If your computers, servers, network devices and databases are already recorded with accurate names, owners and locations, the work is mainly modeling links and validating them with service owners. If records are duplicated, stale or missing, the first phase becomes a cleanup exercise, and that adds time before any diagram is useful. Ask for a timeline that separates inventory assessment, link modeling, review and handover, and confirm which of those phases the fixed scope covers. DeployOpen does not publish durations, so the agreed schedule comes from the written scope.
What must our team provide for an impact analysis project?
Your team needs to provide three things. First, named service owners who can confirm which hardware, software and database instances support each business service and what breaks when they fail. Second, access to the current GLPI instance and exports or read access to the source data for assets, so the team can compare records against what is actually running. Third, reserved time for review sessions, because a map that nobody from the service side has checked will not be trusted during an incident or change. Agree these responsibilities in the scope document before work starts, including who approves the final diagram.
Can our own team build impact analysis without outside help?
Yes, an internal team can build it if it has GLPI administration skills, time to model links and people who understand the services. The usual gap is not the GLPI configuration, which is straightforward once the asset types are enabled, but the discipline of confirming dependencies with service owners and keeping records consistent across entities. Outside help is most useful when the map must cover many services at once, when inventory is poor, or when the same team cannot spare time for review. Compare the internal effort, including the time of service owners, with a written scope from a partner before deciding.
Which GLPI version do we need for impact analysis?
Impact analysis is part of GLPI, so you do not need a separate plugin for the core diagram. The supported versions are the current releases, and the requirements change between them. GLPI 12.0.0 was released on October 7, 2026, GLPI 11.0.11 on October 1, 2026, and GLPI 11.0.0 on October 1, 2025, according to the glpi-project/glpi releases page. GLPI 11.0 requires PHP 8.2 or later with MySQL 8.0 or MariaDB 10.6, while the main branch README lists PHP 8.3 or later with MariaDB 10.11 or MySQL 8.0. Confirm the target version and the database requirements before you start, because the upgrade path can change the way plugins behave and the modeling plan depends on the version you run.
How do we keep the dependency map current after changes?
The map stays accurate only if changes to infrastructure are recorded in GLPI when they happen. Teams need a rule that says who updates a link when a server is added, moved, replaced or decommissioned, and a review cadence set by the service owners. Automated inventory through GLPI Agent helps keep hardware and software records fresh, but it does not decide which business service depends on a database or cluster, so those links still need a human owner. Ask the partner to document the upkeep process, the roles involved and the review schedule as part of the handover, since this work recurs for as long as the services run.
Does DeployOpen issue compliance evidence from the dependency map?
No. DeployOpen prepares systems, controls and records that can support a compliance assessment, including documented asset and dependency records from GLPI. It does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make that judgment. Ask how the records will be presented, what they show about ownership and review dates, and which parts an auditor will need to test independently.
How DeployOpen scopes and delivers impact analysis work
DeployOpen plans, builds, documents and supports GLPI impact analysis inside infrastructure you control. We start from the services your business depends on, then model the assets that carry them, so the dependency diagrams reflect how your environment actually runs. Engagements are fixed-scope, with the scope and deliverables agreed in writing before work starts.
How we scope
- Inventory which asset types you need in impact analysis, such as appliances, clusters, databases, racks and custom definitions.
- Agree the business services to model and the owners who confirm each service's components.
- Put the scope, deliverables and timeline in writing before any configuration changes are made.
How we build
- Configure impact and dependency relations in GLPI and record the direction and meaning of each link.
- Model appliances and clusters so a service diagram follows the hardware and virtual machines behind it.
- Test diagrams against known failure scenarios and correct links that do not match the live environment.
How we hand over
- Document the relation conventions, asset types and link ownership so your team can extend the model.
- Walk through saved and exported diagrams with the people who will use them during change reviews.
- Hand over the configuration and documentation as deliverables listed in the written scope.
How we support
- Offer ongoing support for GLPI upgrades and changes to the impact model as services move or retire.
- Review dependency data periodically with your service owners so diagrams stay current.
- Provide continuous support and upgrades through a retainer if you prefer a standing partner.
