GLPI ships with a feature that most administrators never fully explore: custom fields. Before reaching for a plugin or writing a single line of PHP, check what the built-in field system can do. It covers more ground than you might expect.
What custom fields actually are
Custom fields let you attach additional data points to nearly any GLPI object type -- tickets, computers, monitors, users, contracts, and more. Each field gets a label, a type (text, dropdown, date, yes/no, number), and a position in the form layout. The data is stored natively in GLPI's database and appears in search results, exports, and reports just like any standard field.
This is different from the "Additional fields" plugin, which adds its own database tables. The built-in system is lighter, requires no plugin maintenance, and survives GLPI upgrades without compatibility worries.
When to use custom fields vs. existing fields
Before creating anything, audit what GLPI already provides. The "Location" field on assets, for example, already supports a tree structure -- you can define Building > Floor > Room without any customization. The "Group" field on tickets already handles team routing.
Create a custom field only when no existing field covers your need. Common legitimate use cases:
- Adding "Cost center" to tickets so finance can allocate support costs per department
- Adding "VIP flag" to users so business rules can escalate their tickets automatically
- Adding "Building" or "Floor" to asset records when your location hierarchy doesn't map to physical structure
- Adding "Contract reference" to link tickets to a specific SLA agreement
Dropdown management
Dropdowns are GLPI's mechanism for controlled value lists. Navigate to Setup > Dropdowns to see dozens of built-in lists (ticket categories, locations, manufacturers, operating systems). You can add entries to any of these, and you can create entirely new dropdown lists for custom fields.
Keeping dropdowns clean
A dropdown with 200 entries is worse than a free-text field -- users just pick the first thing that looks close. Aim for 5-15 entries per dropdown. If you need more granularity, use a tree structure (parent > child) instead of a flat list.
Review dropdowns quarterly. Merge duplicates, archive unused values, and check whether agents are consistently selecting "Other" -- that usually means a real category is missing.
Custom fields and business rules
This is where custom fields become genuinely powerful. GLPI's business rules engine (Administration > Rules) can read custom field values and act on them. Practical examples:
- If the requester's "VIP flag" is set to Yes, automatically assign priority "High" and route to the senior support group
- If a ticket's "Cost center" matches "Executive," skip the first-level queue entirely
- If an asset's custom "Criticality" field is "Production," apply a shorter SLA
The rule engine evaluates conditions in order, so place your custom field rules after the standard classification rules. Test with a few sample tickets before going live.
The maintenance problem
Custom fields are easy to create and hard to remove. Once data exists in a field, deleting it means losing that data. Once reports depend on a field, removing it breaks those reports.
Practical limits to follow:
- No more than 5-7 custom fields per object type. If you need more, reconsider your data model -- you might be tracking something that belongs in a separate GLPI object or a linked database.
- Document every custom field: what it's for, who requested it, and which business rules or reports depend on it.
- Require approval before creating new fields. Without a gate, you end up with 50 fields and no one remembers what half of them mean.
Custom fields are one of GLPI's strongest built-in tools. Used with restraint, they turn a generic ITSM platform into something that fits your organization precisely. Used without restraint, they turn it into a data swamp. The difference is discipline, not technology.