Custom fields in GLPI with the Fields plugin

When teams need custom fields in GLPI and what the Fields plugin covers

Teams need custom fields in GLPI when the data they must record on tickets, assets or users does not fit the core forms: a contract reference on a computer, a business owner on a user, or a change risk rating on a ticket. The Fields plugin adds those fields to the objects GLPI already manages, so the work is scoping which fields are needed, configuring them and planning how they carry through a GLPI upgrade. Implementation is usually worth scoping when several technicians would otherwise store the same data in free-text descriptions, or when reports cannot be filtered on information that lives in comments. The plugin is one of the tools in the GLPI plugins and extensions group, alongside purchasing, customer credits, carbon reporting, AI summaries and anonymization, and it should be chosen for the data gap it closes rather than installed by default.

The first decision is the data model. Before anything is configured, list each field with its owner, the object it attaches to, its type, whether it must be filled in before a ticket can be saved, and which people can read or edit it. Those answers determine how the fields are grouped into containers, which control where they appear, and how per-profile rights limit visibility for requesters, technicians and administrators. Confirm with the plugin's current documentation which field types and container options the version you plan to run supports, since these change between releases. Also confirm whether the Fields plugin is compatible with the GLPI release you target, because GLPI 11 changed how plugins are handled.

What the Fields plugin adds to GLPI

The Fields plugin lets administrators attach their own data to tickets, assets and users without changing GLPI's code. The cards below follow the questions an administrator asks in order: where the field lives, what kind of data it holds, whether it must be filled in, and who can see or edit it. Each card names what to confirm in the plugin documentation for the version you run.

Where can the field live?

Start by asking which item type the field must appear on. The plugin documentation describes containers that attach to item types, so a single container can serve tickets, assets or users. Check which item types your installed version supports, and whether a container can be limited to particular entities or categories. Confirm this before building fields, because moving a container later can leave existing data attached to the wrong place.

What kind of data does it hold?

Next, decide the data type: free text, number, date, dropdown or another type. The field type controls validation and how the value is filtered in searches and reports, so a number stored as text will sort and total incorrectly. List the field types your plugin version offers and map each business attribute to one of them. Test a sample value in a search before you roll the field out.

Must the field be filled in?

A required field blocks a form from being saved until a value is present. Use this only where the business process genuinely depends on the value, such as a cost centre on a purchase request, because required fields on closed or legacy items can stall updates. Confirm how the plugin treats required fields during bulk updates, imports and API writes, since those paths may bypass form validation.

Who can see and edit it?

Per-profile rights decide whether each GLPI profile can view, create or modify a field. Map this to your existing profiles rather than creating new ones for each field, and decide whether requesters should ever see technician-only data. Confirm in the plugin documentation whether rights apply to the field only or also to the item it is attached to, and test the result with a test account for each profile.

How do fields survive upgrades?

Custom fields store their definitions and values in the GLPI database, so they must be included in every backup and checked after each update. Before a GLPI 10 to 11 move, confirm that the plugin version you plan to use supports your target release, because plugins are suspended after a new version is detected and must be reactivated. Keep a record of each field's type, container and rights so you can rebuild it if the migration fails.

Which container, field type and rights model fits your data

This table compares the main Fields plugin decisions: which item type a field attaches to, which field type fits the data, whether a field is required, and how read and write access is granted per profile. Read each row as a question you must answer before building, since each choice changes what reports, forms and access controls can do later.

Decision	Choose when	What it affects
Attach to tickets	The data describes a request, incident or work item, such as a customer reference or a change window	Ticket forms and ticket reports; fields do not follow the asset or user unless you add them there too
Attach to assets	The data describes equipment or software records, such as a rack position or a licence owner	Asset forms, asset searches and inventory exports; check how imported inventory data fills these fields
Attach to users	The data describes a person, such as a cost centre or an employee badge number	User profiles and any user-based reporting; confirm how the field behaves when accounts are synced from directories
Dropdown or structured list	Values must be consistent for reporting and filtering, such as region or service tier	Enables clean grouping in reports; requires agreeing the value list with data owners before build
Free text or long text	Values are descriptive and unpredictable, such as a note about a special handling need	Harder to report on and search consistently; keep these few and clearly labelled
Required field	Missing data would block a process, such as a mandatory legal entity on a contract-linked asset	Users cannot save the form without it; test the impact on imports, API writes and automated ticket creation
Optional field	Data is useful but not essential at creation time, or is filled later by technicians	Reports will show gaps; define who completes the data and how you measure completeness
Read-only per profile	Requesters or other profiles should see the value for context but not change it	Protects authoritative data; confirm which profiles need visibility across entities
Write access per profile	Specific technician or administrator profiles own and maintain the value	Limits accidental edits; review profile rights after each GLPI upgrade, since rights models can change between versions

How a Fields plugin rollout runs from requirements to go-live

The sequence moves from a documented data gap to a tested, migrated and trained configuration, with each step producing an artifact the next step depends on. Skipping the early artifacts usually shows up later as rework in containers, rights or migrated records.

Inventory the data gaps
Start by listing the information your technicians keep outside GLPI today, such as spreadsheets, email threads or ticket comments, and mapping each item to the object it describes: tickets, assets or users. A DeployOpen engineer typically runs this with your service desk lead and asset owner, then confirms each gap against the question it answers in daily work. The step is done when every gap has an owner, a business reason and an object type, and the list has been agreed in writing.
Confirm GLPI version and plugin compatibility
Record the GLPI version you run or plan to run, then check the Fields plugin release that matches it in the plugin's own documentation and the GLPI marketplace. Confirm the PHP and database versions against the GLPI prerequisites, since GLPI 11.0 documents PHP 8.2 or later with MySQL 8.0 or MariaDB 10.6, and the README on the main branch lists newer minimums. The output is a short compatibility record naming the GLPI version, plugin version, PHP and database versions, and any open issues the vendor documents for that pairing.
Design containers and field specifications
Group the gaps into containers attached to the right object types, then write one specification per field: label, internal name, field type, allowed values, default, whether it is required, and where it appears in forms and lists. Keep names stable, because reports, rules and integrations will reference them later. The closing artifact is a field specification sheet reviewed by the service desk lead, the asset owner and a GLPI administrator, with each required field justified by a business rule.
Set profile rights for each field
Map every container and field to the GLPI profiles that need to read or write it, starting from the access model you already use for profiles and entities. Decide explicitly which fields are visible to requesters, which are restricted to technicians and which only administrators can change, because a field that is hidden from one profile can still appear in exports or search for another. The step closes with a rights matrix showing each profile against each field and the action it allows.
Test with representative profiles
Create test accounts that match each real profile and entity combination, then run the scenarios that matter: creating a ticket, editing an asset, saving a user with a required field left empty and searching on a custom value. Record each result against the specification, including what a requester sees versus a technician. Use a non-production instance for this work. The output is a signed test record listing each scenario, expected result, actual result and any defect fixed before go-live.
Migrate existing data into the new fields
Decide how historical records get values: leave them empty, backfill from a spreadsheet or derive them from existing data. Load a sample first, check counts and a set of spot-checked records, and only then run the full load on a copy of production. Pay attention to required fields, since historical records may not satisfy them until backfilled. The closing artifact is a migration log with source counts, loaded counts, rejected rows and the owner who accepted the exceptions.
Train administrators and publish the change
Train the GLPI administrators and service desk leads on how to add containers, change field rights and interpret the rights matrix, and give them the specification and test record as reference. Confirm the back-out steps, including how to hide a field without deleting stored values. Go-live is complete when administrators can reproduce one scenario from the test record on their own and the change record names who approved the rights matrix.

Moving custom fields from GLPI 10 to GLPI 11 and 12

Custom fields built with the Fields plugin on GLPI 10 need a compatibility check before any upgrade, because GLPI 11.0 was released on October 1, 2025 and GLPI 12.0.0 on October 7, 2026, and the upgrade path changes what the plugin depends on. The key operational fact is that since GLPI 11.0, plugins are suspended once a new version is detected and must be reactivated after major updates. That means a field container that worked yesterday can silently stop showing on tickets, assets or user forms until the plugin is back online. Before scheduling the move, the team should confirm in the Fields plugin documentation which plugin version supports each target GLPI release, and test the upgrade on a copy that holds the same custom field definitions and sample records.

Backups come first, and they must cover three things: the database, the application files and the config directory. The config directory holds glpi.key and glpicrypt.key, which GLPI uses to protect stored secrets. A database restore without those keys can leave encrypted values unreadable, so the team should confirm that the backup set includes both files and that a restore of the set has been rehearsed. The GLPI update documentation describes the sequence of backing up, replacing the application files and running php bin/console db:update, which the Fields plugin upgrade must fit inside. Plan a rollback point for each stage, since a failed plugin reactivation is easier to recover from than a half-migrated schema.

After the upgrade, verify field by field rather than assuming the plugin is healthy. Check that each container still attaches to the intended item types, that required-field rules fire on creation and update, that per-profile rights still hide or expose the right fields to requesters, technicians and administrators, and that existing values appear in reports and exports. Record the results as a dated test log, since that log is the evidence an auditor or internal reviewer will ask for. If the plugin does not yet support the target version, the decision is between waiting, keeping the custom data in a supported alternative, or delaying the upgrade, and that decision should be made in writing with the business owners of the affected fields.

How the environment changes the work

A new GLPI instance has no historical field data, so the main risk is design rather than migration. Teams can define containers, field types and rights before any tickets or assets exist, and test them against a clean dataset. The work is shaped by how many field sets the business actually needs and how early the naming and type decisions are locked.

Field inventory first: List every attribute the business wants on tickets, assets and users, then remove duplicates that existing GLPI fields already cover.
Naming and types: Choose field names and types before creating test records, because changing a type later can strand data already entered.
Profile matrix: Test each GLPI profile against each container, including requesters, technicians and administrators.
Clean-room test data: Create sample assets and tickets in a staging instance to confirm required fields behave as intended.
Installation checks: Confirm the PHP and database versions in the prerequisites for your target release before you build anything on top.

Before sign-off, ask the implementation partner to show the profile matrix results and the list of fields that are required at creation, since those are the ones that most often block users in production.

What drives the cost of adding custom fields

This table lists the components that make up the price and schedule of a Fields plugin project, with what drives each one up and what to ask for in a quote. Use it to compare an internal build with a partner's written scope. DeployOpen does not publish prices, and each quote follows from the scope agreed in writing.

Cost component	What drives it up	How to keep it down	What to ask for in a quote
Containers and fields	Many containers spread across tickets, assets and users, each with its own field set and naming rules	Start with a short list of fields tied to a named report or workflow, and add others later	Count of containers and fields by item type, with the owner of each
Field types and validation rules	Dropdowns fed by external data, date logic, or validation that depends on other fields	Use simple native field types and keep validation in one documented place	Itemized list of field types and each validation rule, with test cases
Rights model complexity	Several profiles needing different read, write or hidden access to the same field	Limit the number of profiles that see sensitive fields and reuse existing profiles	Matrix of fields against profiles showing read, write and hidden rights
Existing data to migrate	Large volumes of tickets or assets that need values backfilled, or values stored in spreadsheets	Backfill only fields that reports need, and clean source data before import	Record counts per item type, source format, and the backfill rule for each field
Integrations that read the fields	Reporting tools, inventory agents, webhooks or APIs that depend on field names or types	Agree field names and types with integration owners before the build starts	List of consumers, the fields each one reads, and the change process for renames
Testing across profiles	Each profile and entity combination needs its own test pass, including mandatory field checks	Test a small set of representative accounts per profile rather than every combination	Test scenarios per profile, entity and item type, and who signs off each result
Documentation and handover	Field dictionaries, admin runbooks and end-user guidance written for several audiences	Keep one field dictionary as the source for admin and user notes	Named deliverables, format, and whether the client's team edits the documents afterward
Upgrade path from GLPI 10	Plugin code or field data that must be checked against the GLPI 11 core and plugin reactivation	Confirm plugin compatibility before the upgrade date and keep the field inventory current	Statement of which plugin versions and GLPI versions the scope covers

How custom fields connect to the rest of GLPI

A custom field is only useful if the rest of GLPI can see it, enforce it and report on it. The cards below cover the points where a Fields plugin container meets authentication, forms, tickets, inventory, integrations and reports, and what to confirm at each one before you build.

Profiles and per-profile rights

Each container and field needs read and write rights per profile, and those rights decide which technicians, requesters and administrators see or change the data. Check how the container targets assets, tickets and users, and whether a profile that can edit a ticket can also edit the field values attached to it. Test with a non-administrator account before rollout, because administrator views hide most rights gaps.

Sign-in sources and user fields

Fields attached to users may be filled from directory attributes, but a value typed by a technician can be overwritten the next time the user signs in through LDAP or another external source. Confirm which authentication source your users come from and whether the sync rules touch the same attributes as your fields. The internal database, LDAP, IMAP and external methods are tried in order, so the first source that accepts a login decides which account data applies.

Helpdesk forms and ticket workflows

Fields shown on a ticket are only as useful as the form and workflow that collect them. Decide which fields a requester fills in at submission, which a technician completes later, and which rules depend on a value being present. Confirm in the GLPI helpdesk documentation for your version how a field interacts with forms, mandatory-value checks and automatic actions, since a field that a rule expects but a form never asks for will leave tickets stuck.

Inventory data from GLPI Agent

Fields on assets are usually filled by hand, but some values such as location codes or ownership tags can also come from inventory. GLPI Agent collects hardware and software data and sends it to GLPI, so a field the agent never writes to will stay empty on newly discovered machines. Decide which values are set by people and which by inventory, and confirm in the Agent documentation that the import rules will not overwrite manual entries.

Outbound integrations and the OAuth2 API

External systems read and write GLPI data through the API, so a custom field has to be exposed there before a connected tool can use it. Check whether the plugin version you run makes container fields visible through the API, how the field is named in responses, and what the OAuth2 client scopes allow. Test one read and one write with a service account, and record the field identifiers, since a later rename breaks the mapping on the other side.

Reporting and data governance

Standard GLPI reports only show custom fields when the plugin and the report tool support them, so a value you collect may not appear in the dashboards your managers use. Confirm which report views list container fields, how empty values are shown, and whether exports keep the field labels. Because field data often holds personal or sensitive information, also review who can export it and whether the anonymization steps are needed for test copies.

Questions teams ask before adding Fields plugin data

How long does adding custom fields to GLPI take?

The length depends on scope, and no duration is set for this work until the field list is agreed. The main drivers are the number of containers (tickets, assets, users), the number of field types, any conditional display or required-field rules, and how many profiles and entities need different visibility. A GLPI 10 to 11 move, a test cycle with each profile, and documentation for administrators all add time. DeployOpen usually works to a fixed scope agreed in writing before work starts, so the timeline comes with that written scope. To prepare, ask for a field inventory with one row per field and a rights matrix that lists which profile sees and edits each field.

Can one internal GLPI administrator add custom fields alone?

Yes, for a small change on one container in a test instance, if that administrator understands GLPI profiles, entities and database backups. The work gets harder as per-profile rights multiply, because a wrong permission can expose or hide data without any visible error. Before starting, confirm the plugin's installation and permission requirements in its own documentation, and set up a staging copy of the instance. A single administrator also needs a reviewer for field design, since mistakes in required fields or rights are easy to miss alone. DeployOpen can build the change, review an internal build, or take on the whole scope.

What does the work need from our team?

The work needs decisions from the business more than technical access. Expect to provide:

A named owner for each field who can say what values are allowed and who may read them.
A list of profiles, entities and groups, with the access each one should have.
A staging GLPI instance that matches production closely enough to test forms and rights.
Server or container access for the changes, plus a backup window agreed with operations.
A test group of technicians and requesters who can check each profile before go-live.

Without the owners and the rights matrix, most delays come from open questions about who should see what, not from the build itself.

Do custom fields survive a move from GLPI 10 to GLPI 11?

Do not assume they do. Confirm that the Fields plugin version you use supports the GLPI version you are moving to, and test the move on a copy first. GLPI 10.0.0 was released on April 20, 2022, and GLPI 11.0.0 on October 1, 2025. The GLPI update procedure requires a backup of the database, the files and the config directory, including glpi.key and glpicrypt.key, before application files are replaced and db:update runs. Since GLPI 11.0, plugins are suspended when a new version is detected and must be reactivated after major updates, so check each field's data and rights after reactivation. Keep the rollback path documented before the upgrade starts.

What changes for end users after custom fields are added?

Users see new questions on the forms or pages where the fields are placed, but only for the profiles that have rights to them. Required fields will block saving until they are filled, so a required field added to a busy form can slow requesters down if the rule is not explained. Search, filters and reports may also show the new data, which changes what technicians can find. Test each profile with real sample records and check the screens, not only the configuration. Confirm the exact display behavior in the plugin's documentation and in your test instance before you publish the change.

Is custom field data a security risk in GLPI?

It can be, if the field holds sensitive information and its rights are wider than the data needs. Classify each field before building it, then restrict read and write rights per profile. Check where the data can appear beyond the screen, including exports, notifications, API responses and reports, since a field that is hidden on a form may still be visible elsewhere. Review the audit trail expectations for changes to these fields with your security team. For sensitive categories, confirm the plugin's behavior in the test instance and record the result as evidence.

Does the Fields plugin need a GLPI Network subscription?

Confirm this with Teclib' and the plugin's own documentation before you budget, because the answer depends on how the plugin is published. The GLPI Network subscriptions page lists self-hosted subscriptions from 100 euros per month (Basic, up to 10 agents and 500 assets) to 4,500 euros per month (Enterprise), with level 3 support and GLPI Network marketplace plugins. Support differs between Teclib-published and community plugins, so ask who supports the plugin version you will run and how security fixes are delivered. Ask for this in writing as part of the scope.

What does a partner hand over when the fields work is finished?

Handover items are agreed in the written scope, so ask for them by name before signing. Typical deliverables include the field specification, the rights matrix for each profile, configuration notes, test results for each profile, the backup and rollback steps used for the change, and a short guide for administrators who will maintain the fields. Ongoing support, upgrades and testing can be taken on as a retainer after the build. DeployOpen does not issue audit reports or certifications, so any compliance evidence it prepares is input for your independent assessor.

What you keep after the custom fields go live

The handover package is what lets your team maintain the Fields plugin configuration without us. It should contain the field specification (each field's container, type, label, whether it is required, and the reason it exists), the container and rights matrix showing which profiles can read or write each field on tickets, assets and users, the migration records for any data moved or backfilled, the test evidence from the validation pass, and a backup and update runbook. After go-live, your team owns the field specification and the rights matrix, because those change with your business. The migration records and test evidence belong to your change record and audit trail, so they should be stored where your compliance lead can retrieve them. The runbook is shared: your platform team runs the backups and updates, and it must include the step to reactivate plugins after a major GLPI update, since GLPI 11.0 suspends plugins when it detects a new version.

Ask us to confirm in the runbook exactly which backup set covers the Fields plugin configuration. The GLPI update procedure requires backing up the database, the files and the config directory, including glpi.key and glpicrypt.key, before replacing application files and running php bin/console db:update. A field definition stored in the database is only recoverable if the database backup is restorable, and any encrypted values depend on the key files, so a restore test should be part of the runbook. Record the plugin version next to the GLPI version in the runbook, because plugin releases must match the GLPI release in use. Confirm with the plugin's publisher which versions support your target GLPI release before the upgrade window is booked.

Admin training notes are the last item and the easiest to skip. Write them for the administrators who will add the next field, covering where each container is configured, how the rights matrix maps to GLPI profiles, and what a required field does to existing tickets and forms. A retainer for ongoing support is worth considering when you expect frequent field changes, a GLPI major upgrade within the next year, or a plugin update cycle your team cannot staff. Ask any partner to price the retainer against a written scope covering who performs upgrades, how plugin reactivation is tested, and how changes to the rights matrix are reviewed before they reach production.

How DeployOpen scopes and delivers GLPI custom field work

DeployOpen approaches custom fields for GLPI as a planned change to tickets, assets and users, not a quick form edit. Each engagement starts with a written scope that defines the containers, field types, rights and migration steps, then builds and tests them in an instance you control.

How we scope

Inventory the ticket, asset and user fields your teams need and the reports that depend on them.
Map each field to a container, field type and required or optional setting in writing.
Define per-profile visibility and edit rights for technicians, requesters and administrators.

How we build

Build the containers and fields in a non-production GLPI copy before any change reaches production.
Test required-field behavior on ticket creation, asset import and user sync paths.
Check each profile's rights with test accounts that mirror your real roles.

How we hand over

Document each container, field definition, rights rule and the reason it exists.
Record the plugin version and GLPI release the configuration was tested against.
Write a migration runbook covering the GLPI 10 starting point and plugin reactivation after updates.

How we support

Offer ongoing support, upgrades and testing as a retainer after the fixed-scope work closes.
Review field and rights changes before each GLPI or Fields plugin upgrade you plan.
Confirm with the plugin publisher which GLPI versions the Fields plugin supports before you commit.

Adding custom fields to GLPI with the Fields plugin