An asset record in isolation tells you what something is. An asset record linked to its user, location, contract, and ticket history tells you what it does, who depends on it, and what happens when it breaks. GLPI is a relational system, and the relationships between objects are where the real operational value lives.
How GLPI’s relational model works
Every major object type in GLPI can be linked to other object types. A single computer record, for example, can carry connections to:
- A user (who has the device) and a group (which team they belong to)
- A location (building, floor, room, rack position)
- One or more contracts (warranty, maintenance, lease)
- A supplier (who sold or services the device)
- A history of tickets (incidents and requests that involved this device)
- Installed software (each linked to its own license record)
- Connected peripherals (monitors, docking stations, printers)
These are not just informational labels — they are navigable links. Click from a computer to its contract, from the contract to all other assets covered by it, from any of those assets to their open tickets. This web of connections is your CMDB.
Why relationships matter for impact analysis
When a switch fails, the first question is always: what is affected? Without relationships, you are making phone calls and checking spreadsheets. With a properly linked CMDB, you open the switch record in GLPI and see:
- Its location (Server room B, Rack 3)
- Connected devices (12 servers, 2 NAS units, 4 access points)
- Users assigned to those devices (28 people across two departments)
- Active SLA contracts on affected services
That chain of information — from failed component to affected users — takes seconds to trace when the relationships exist. Without them, it takes the entire duration of the outage.
Setting up the "associated items" feature
GLPI’s associated items tab appears on most asset types. The practical steps to make it useful:
Asset-to-user assignment
Assign every deployed asset to both a user and a group. The user tells you who has it; the group tells you which team is affected when it is unavailable. When an employee leaves, reassigning their assets becomes a simple update rather than an inventory hunt.
Asset-to-location mapping
GLPI’s location hierarchy supports multiple levels — Country > City > Building > Floor > Room. Populate this once in Setup > Dropdowns > Locations and assign each asset. Physical audits become straightforward: filter by location, print the list, walk the floor.
Asset-to-contract linking
Link each asset to its relevant contracts under the Management tab. A single asset might be covered by a hardware warranty, a maintenance contract, and a software support agreement — each a separate contract record with its own expiration date.
Asset-to-ticket history
This link is created automatically whenever a ticket references an asset, building a reliability profile over time. A computer with 12 tickets in the past year is telling you it needs replacement, not another repair.
Practical example: tracing an incident
A user reports that printing does not work. The helpdesk opens a ticket, associates it with the user’s computer, and sees the connected printer. The printer record shows its location (third floor) and an active maintenance contract — so they call the vendor directly, referencing the contract number from GLPI. Three clicks, zero guesswork.
The key discipline is consistency: every asset gets a user, a location, and a contract link at deployment time. Treat relationship data as mandatory fields, and the CMDB stays useful instead of decaying into an unreliable list.