Asset states and transitions in GLPI: configuring the lifecycle

An asset's status — the Status field in GLPI — is just one entry in a dropdown. For an operations team, it decides whether the device counts toward production, whether it should go through maintenance, or whether an admin can wipe it on intake. A configured state machine is the difference between a working inventory and a spreadsheet with a "status" column.

Default states

GLPI installs with a minimal set: In stock and In production. For most organizations that's not enough. Under Setup → Dropdowns → Asset states you find the actual state controls — that's where you add custom states and define which object types they apply to.

A practical baseline set we recommend as a starting point:

• Procurement — ordered, not yet received.
• In stock — physically in the warehouse, ready to deploy.
• In production — assigned to a user or deployed at a production location.
• In repair — at the service center, temporarily out of operation.
• Loaned — short-term loan (a corporate laptop on a business trip, a temporary replacement).
• Retired — decommissioned but not yet disposed of (typically waiting for wipe or recycling).
• Disposed — physically destroyed; the record stays for accounting and audit.

Seven states cover the vast majority of scenarios. If you start adding more, it usually means you're modeling a process that belongs elsewhere — a ticket workflow or change-management flow.

Allowed transitions

GLPI itself does not enforce which state can follow which. An asset in Disposed can technically be flipped back to In production by anyone with edit rights. For a disciplined process you must enforce transitions in two ways:

1. RBAC restrictions — only specific profiles can change the state, and only between certain values. A helpdesk technician can flip In production ↔ In repair, but cannot set Disposed — only the asset manager can.
2. Business rules (Administration → Rules → Rules for assets) — a state change can automatically populate a field, create a ticket, or send a notification. Example: a transition into Retired automatically opens a ticket for IT-security with the task "wipe disk".

A typical allowed-transition graph:

Procurement → In stock → In production
                          ↓ ↑
                       In repair
                          ↓
                       In stock (after repair)
                       or
                       Retired → Disposed

Loaned: parallel to In production, returns to In stock

Audit trail

Every state change is logged in the asset's history (the Historical tab). The record contains: previous state, new state, who made the change, when. For compliance audits (ISO 27001, NIS2) this is the primary evidence that you control the hardware lifecycle.

For regulated environments we recommend supplementary logging via Business Rules — on every transition into or out of sensitive states (Disposed, Retired) automatically append a record to a separate audit log table or send a notification to audit@company.

Design for a laptop fleet

A worked example for 200–300 corporate laptops:

• Procurement → In stock — when a laptop physically arrives, a technician changes the state and fills in serial number, MAC address, and warehouse intake.
• In stock → In production — at user issue the "User" field is filled, state changes, and an "Onboarding device" ticket is auto-created with subtasks (software install, smoke test, handover signature).
• In production → In repair — when a user reports a fault via a ticket, the asset state change triggers a follow-up ticket for the service center.
• In production → Retired — at fleet refresh (a 3–4 year cycle). A ticket is auto-created for IT-security to wipe the disk.
• Retired → Disposed — after wipe and recycling complete. The record stays on file for accounting with current depreciation.

Design for a server estate

For servers the cycle has a different rhythm — physical kit changes every 5–7 years, but the states must accommodate planned maintenance:

• In production ↔ Maintenance — add a custom Maintenance state distinct from In repair, because planned maintenance is a different operation from an unplanned fault.
• Decommissioning as an intermediate state between In production and Retired — data is migrated, services are moved, the server stays physically active for several weeks.
• For larger installations (over ~50 servers) add Standby — server ready for fast deployment but currently unused.

States aren't documentation. They're switches that fire the rest of the process — tickets, approvals, audit records. The investment in deliberate design pays off at every audit and at every fleet handover to a new operator.