When teams model custom GLPI asset types
Teams model custom GLPI asset types when their inventory needs classes GLPI does not ship with, such as separate server or laptop records, and they want those classes to behave like first-class assets rather than as loose fields on an existing type. Asset definitions are the GLPI mechanism for this. The question is less whether GLPI can hold the data and more whether the new class has its own lifecycle, its own users and its own integrations, which is the point where it earns a definition of its own. This workstream is usually scoped separately from the core GLPI install because it changes the data model that other people build on. The GLPI asset definitions documentation states that the system name of a custom asset cannot be changed later and is what development uses, for example in API calls and webhooks. A name chosen in a rush can therefore stay in scripts and integrations for years. It also states that a new definition needs profile access configured before anyone can use it, so the rights model, the naming and the test data have to be agreed before the first record is created.
Before scoping the work, confirm with the GLPI documentation which capacities your asset class needs. The documentation describes capacities as behaviors added to a custom asset, such as linking antivirus, appliances, certificates, components, connections and contracts. Each capacity you enable changes what a technician sees and what an integration can attach to, so the list should come from the reports, contracts and support processes the asset supports. Ask whether the Fields plugin would cover the need instead, and make that comparison in writing with the names, capacities and access rules for each option.
What GLPI asset definitions do
A GLPI asset definition creates a new asset type that the core does not ship with, such as separate server or laptop records. Each definition has a permanent system name, optional capacities that add linked behaviors, and profile rights that decide who can see and use it. The cards below cover those pieces in the order a team usually decides them.
Defining a new asset type
An asset definition gives your organization its own record type, such as a server or laptop, instead of forcing those items into a generic model. Each definition carries its own name, fields and item list, so technicians see the category they expect. Before building, list the attributes each type needs and check whether they differ enough to justify a separate definition. Confirm the exact fields and screens in your GLPI version against the documentation.
The permanent system name
Every definition has a system name that developers use in API calls and webhooks. The documentation states that this name cannot be changed later, so a mistake becomes a long-lived integration problem. Choose a stable, lowercase, descriptive name before any script or webhook refers to it. Ask your integration owners to review the name alongside the display label, which can change without breaking code.
Capacities add linked behaviors
Capacities switch on behaviors for a custom asset, such as linking antivirus products, appliances, certificates, components, connections and contracts. Enable only the capacities a team will maintain, since each one adds data that someone must keep current. A server type that links contracts supports renewal tracking, while one that links components supports hardware detail. Review each capacity with the owners who will enter the data.
Profile access before use
A new definition does nothing for anyone until profile access is configured. The documentation requires this step, so users without the right rights will not see or create the new type. Assign rights per profile deliberately, starting with the technicians who manage the category. Test with a standard user account and an administrator account before announcing the change.
Checks before go-live
Before users start entering records, run a short review of the definition: system name, labels, enabled capacities, profile rights and a sample record. Confirm that imports and integrations use the system name you approved. Record the decisions in your configuration documentation so later upgrades and audits can trace why each setting exists. Ask your partner or internal team to repeat the review after each GLPI upgrade.
Why the system name is a permanent decision
The system name of a custom asset type cannot be changed after the definition is created, and it is the identifier developers use in API calls and webhooks. Treat the choice as an integration decision, not a labeling detail. Before anyone creates the definition, agree the name with the people who will build against it: the owners of the API consumers, the webhook receivers, any reporting or data pipelines, and the GLPI administrators who will maintain the definition. A rename later is not a cheap fix, because every integration that references the old name has to be found, changed and retested, and records already created under that definition carry the old identifier with them.
Agree a naming convention across all asset classes before the first definition is built, so that separate server, laptop and similar types do not drift apart. Decide the casing style, whether names describe the physical class or the business role, whether to use a common prefix for in-house types, and how to avoid names that collide with core GLPI asset types or with names reserved by plugins you already run. Write the convention down with two or three example names, and have the integration owners sign off on it. Keep the list of agreed names in your change records so that a later request for a new type can be checked against it.
Before go-live, check the API and webhook configuration against the system name you chose, in a non-production instance first. Confirm that the API client account can read and write the new type, that each webhook subscription targets the intended event for that type, and that the receiving systems parse the payload fields you expect. Confirm the exact endpoint paths and event identifiers in the GLPI documentation for your version, since they are not set out here. Also confirm that profile rights are in place for the people and service accounts that will use the type, because the GLPI asset definitions documentation notes that no one can use a new definition until profile access is configured. Record the final names and the test results in your runbook so the next team can see what was built and why.
Asset definitions or the Fields plugin
Choose a custom asset definition when the thing you track behaves like a distinct kind of asset. Separate servers, laptops or network appliances that your organization manages with their own statuses, owners, relations and lifecycle usually fit this pattern. A definition gives the class its own system name, its own item list and its own profile rights, so it does not have to share screens or permissions with computers or other core types. Capacities then add linked behaviors, such as contracts, connections or components, without custom code.
- Its own lifecycle: Records of this class can carry statuses and transitions that make sense for that class and do not distort the core types.
- Its own relations: Capacities such as contracts, connections or components attach to the class in a way the reader can inspect in the interface.
- Its own rights: Profiles can grant access to the new class without widening access to computers or other existing types.
- Its own API identity: The system name is fixed after creation and becomes the identifier used in API calls and webhooks, so choose it deliberately.
- Its own reporting surface: Searches and exports start from the class, which keeps counts and filters clean.
Before you commit, confirm the capacities and rights model against the GLPI documentation on asset definitions in your target version.
Extra attributes suit situations where the records remain the same kind of thing and you only need more fields on them. An example (illustrative) is recording a rack position code or an internal cost center on existing computer records. Adding fields keeps the existing lifecycle, relations and reports intact, and avoids creating a parallel asset type that technicians must learn. The cost is that the new fields inherit the rights and views of the asset type they extend, so you cannot give one group access to the attribute alone without accepting the surrounding record.
- Smaller data model change: Existing assets keep their types, links and history, and nothing has to be migrated between classes.
- Shared rights: Access to the extra values follows access to the host record, so plan profiles around the whole record.
- Shared reports: Existing searches and dashboards pick up the new fields, which helps when the attribute is a filter for many reports.
- Limited behavior: Extra attributes store values. They do not add a lifecycle, a set of relations or an independent item list.
- Migration risk: If the attribute later becomes a real asset with its own history, moving it into a new class is more work than deciding early.
Confirm how the Fields plugin handles visibility, rights and export in your installed version by reading its own documentation, because plugin behavior can change between releases.
The data model is the first place the two options diverge. A custom asset definition creates a new item type with its own table, identifiers and relations, so records are first-class objects that other parts of GLPI can reference. Extra attributes add columns or values to an existing item type, so they are attached to records that already have a type, links and history. Neither option should be chosen only by how many fields you need. Count the number of distinct states, relations and owners the thing has, then decide.
- Identity: A new class gets its own system name that development will reference, while extra attributes reuse the identity of the host type.
- Relations: Capacities let a new class connect to contracts, connections, components and similar objects, which extra attributes cannot do by themselves.
- Lifecycle: A class can carry its own status logic, while attributes depend on the host record's lifecycle.
- Migration: Changing from attributes to a class later requires moving records and their links, so test the move on a copy.
- Naming: Pick the system name and labels with API consumers and report writers in the room, because the system name cannot be changed later.
Ask the implementation team to show you the table and identifier for each option in a test instance before choosing.
Rights and reporting follow the data model, and they are where many deployments run into trouble. A new definition needs profile access configured before any user can see or create its records, so the default state is that nobody has access. Extra attributes are governed by the rights already granted on the host record, which is simpler to administer but less precise. For auditors, the question is whether the people who can change a value are the same people who are accountable for it.
- Profile design: Define who creates, edits, views and deletes records of the new class, and grant those rights explicitly per profile.
- Scope of access: Confirm whether the new class follows entity and sub-entity visibility the way you expect.
- Attribute exposure: Check whether extra attribute values appear in exports, API responses and search results for every profile that can view the host record.
- Reporting shape: Class-based reports give clean counts per asset type, while attribute-based reports need filters that remain stable over time.
- Evidence: Keep a record of the rights matrix and the test users used to verify it, since it supports later access reviews.
Confirm the Fields plugin's rights behavior and export behavior in your own environment, using its documentation and a test account for each profile.
A short set of questions usually settles the choice. Work through them with the people who will own the data, the people who will build reports and the people who will administer access. Write down the answers, because the decision affects naming, rights and migration later. If several answers point in different directions, a custom class is often the safer option for anything with its own history, while extra attributes suit lightweight classification of records that already exist.
- Own lifecycle? If the thing has its own statuses, transitions and owners, lean toward a new class.
- Own relations? If it must link to contracts, connections or components, a capacity on a new class is the better fit.
- Same kind of record? If it is still a computer or another core type with more detail, extra attributes are usually enough.
- Access split? If one group must see the data without seeing the host record, plan for a separate class.
- Reporting needs? If reports must count the thing separately, a class gives cleaner results.
Before you build, confirm current Fields plugin behavior and the asset definitions behavior for your target GLPI version in a test instance.
Decisions to settle before creating a definition
This table compares the configuration choices you make when creating a custom asset definition in GLPI. Read each row as a decision: the option, when it fits, and what it affects once records exist. Most of these choices are hard to undo, so settle them with the people who will use and report on the asset type.
| Decision | Option and when it fits | What it affects later |
|---|---|---|
| System name | Short, stable, developer-facing identifier. Choose it before any integration is written, since it is what API calls and webhooks reference. | The system name cannot be changed later, so a poor choice persists in every integration, script and webhook payload. |
| Label and language | Human-facing name shown to technicians and requesters. Set it per the languages your users work in. | Labels appear in menus, forms and reports. Changing a label is easy, but it does not alter the system name. |
| Capacities to enable | Enable only the behaviors the type needs, such as contracts, connections, components or certificates. Add more later if needed. | Each capacity adds tabs, links and data relationships. Enabling them early means more records to maintain and more fields to govern. |
| Contracts capacity | Needed when servers, laptops or other assets carry support, maintenance or lease terms that finance and renewal alerts must track. | Links to contract records and renewal notifications. Without it, support terms stay in spreadsheets or the Fields plugin. |
| Connections capacity | Needed when assets connect to each other, such as a server to a storage array or a laptop to a docking station. | Creates links that feed relationship views and dependency work. Plan the link direction and naming before data entry. |
| Profile rights per group | Grant read, create, update and delete rights only to the groups that maintain this asset type. Confirm rights with a test account before go-live. | A new definition is unusable until profile access is configured. Missing rights cause silent gaps for technicians. |
| Entity visibility | Decide which entities can see and manage records. Multi-entity organizations usually restrict creation to the owning entity. | Affects who sees inventory in reports, searches and dropdowns, and whether shared records are duplicated. |
| Search and reporting | Decide which fields technicians search on and which fields reports need. Confirm how each field appears in search results and exports in your version. | Field choices determine what can be filtered, exported and audited. Adding fields later is possible, but reports built earlier may need rework. |
| Fields plugin or definition | Use a definition when the type needs its own lifecycle, rights and relationships. Use the Fields plugin for extra attributes on existing types. | Choosing the wrong route leads to later migration. Confirm the current capabilities of both options in your GLPI version before deciding. |
How the implementation runs, step by step
The sequence moves custom asset types from an agreed inventory of classes and attributes to tested, production-ready definitions that people and integrations can use. Each step closes with a named output so the next one starts from something checkable.
Inventory asset classes and attributes
Start by listing every asset class the business needs to track that GLPI does not ship, such as separate server and laptop types, and the attributes each one must hold. Owners from IT operations, procurement and finance usually confirm which fields matter for lifecycle, contracts and reporting, and which existing records already cover the need. The output is a signed-off inventory that maps each class to its attributes, its data owner and the teams who will create and read those records. Ask the implementation team to show which requirements the Fields plugin could meet instead, so the choice is recorded.
Agree system names with integration owners
Before anything is created, agree the system name for each definition with the people who own the APIs, webhooks and reporting that will call it. The documentation states that a system name cannot be changed after creation and that development uses it in calls and webhooks, so a rename later breaks every consumer. Involve the owners of any inbound inventory agents, SSO attribute mapping and downstream exports. The output is a short register of final system names, their owners and the integrations that depend on each one.
Create definitions in a test instance
Build each definition in a non-production GLPI instance first, using the agreed names and the attribute list from the inventory. Keep the instance on the same GLPI version and database engine as production so behavior matches. Record the configuration choices, including field types and any capacities enabled at this stage. The output is a test instance where every definition exists exactly as specified, with a change record that can be replayed in production.
Configure capacities
Enable only the capacities each asset class needs, such as software, network ports, contracts or components, because each one adds behavior and related records. Confirm for each capacity what it links to and how it appears on the asset form, and check the result with the people who will enter data. The output is a capacity matrix listing each definition, the capacities it carries and the reason each one is present, which becomes the reference for later changes.
Set profile access and entity visibility
A new definition is not usable until profile access is configured, so set rights for each profile that needs to create, read, update or purge these assets. Then confirm entity visibility so that technicians in one entity see only the records they should, and sub-entity rules match the organization's structure. Test with accounts from each profile rather than only administrator accounts. The output is a rights matrix and a short test log showing that each sample account can perform exactly the actions it was granted and no others.
Load sample data and test APIs and webhooks
Load a representative set of sample records, including edge cases such as missing serial numbers, duplicate names and assets moved between entities. Then exercise the API calls and webhooks that depend on the system names, checking create, read, update and delete operations and the payload fields the receiving systems expect. Ask the integration owners to sign off on the results. The output is a test report covering each API call and webhook with its expected and actual result, and a list of any defects that must be fixed before promotion.
Promote definitions to production
Apply the tested configuration to production using the change record from the test instance, and confirm that the definitions match the agreed names, capacities and rights. Enable access only for the profiles approved in the test log, then have a small group of real users enter records in a controlled first use. Keep a rollback plan that does not depend on renaming anything. The output is a production configuration that matches the test record, a verified list of active profiles and a first-use review noting any follow-up changes.
Hand over and document the definitions
Document each definition with its system name, attributes, enabled capacities, profile rights, owners and dependent integrations, and store the document where the operations team keeps configuration records. Agree who approves future changes to attributes, since new fields and capacities can be added while system names must stay fixed. The output is a handover pack that operations and integration teams can use to maintain the asset types without reconstructing the decisions made during the build.
What drives the effort and how to keep it down
This table lists the main drivers of effort for a custom asset definition project and how each one can be reduced. Read it as a checklist for the written scope, since the cost of the work depends on how many of these drivers apply to your environment.
| Driver | Why it changes effort | How to keep it down |
|---|---|---|
| Number of asset classes | Each definition needs its own fields, dropdowns, profile rights and test records, so effort grows with every new type. | Start with the classes that have a clear owner and a real inventory need, and add others in a later phase. |
| Capacities per class | Each capacity such as software, network ports, contracts or connections adds behavior that must be tested and documented. | Enable only the capacities the business process uses, and confirm each one against the team that will rely on it. |
| Profile and entity rules | Rights must be set per profile and per entity before anyone can use a new definition, and deep hierarchies multiply the test cases. | Reuse a small set of profiles and keep entity rules flat where the organization allows it. |
| Integration count | Every API client, webhook or inventory import that calls a system name must be built, mapped and tested. | List the consumers before build starts and integrate only the systems that need the new asset type on day one. |
| Data cleanup in source systems | Spreadsheets, CMDB exports and agent data often use inconsistent names, serials and owners, which must be fixed before import. | Profile the source data early, agree a cleanup owner, and load a sample before the full migration. |
| Sign-off on system names | System names cannot be changed after creation and are used by development, so every approver's review adds a delay. | Gather naming decisions in one review with the developers and asset owners, and keep the list short. |
| Cost basis | Fees follow the written scope, so each driver above should appear as a line item in the statement of work. | Ask for a quote that separates definition design, rights, integrations, data loading and training. |
How custom assets connect to the rest of GLPI
A custom asset type is only useful if the rest of GLPI can see it, feed it and control access to it. The cards below cover the connections to plan for before you create the definition, what each one needs from the asset definition, and the settings to confirm in your GLPI version.
Inventory agent and import rules
Agents and import rules create or update asset records automatically, but they only match assets that GLPI already knows how to represent. If your custom type is a separate server or laptop class, check whether the agent's inventory data maps to it or whether records must be created and updated by an import rule. Confirm how your GLPI version and inventory plugin handle custom types before you rely on automatic creation, and test one device end to end.
Contracts and financial records
Contracts are linked to assets through capacities, so a custom type that needs maintenance or support terms must enable the contract capacity. Plan who owns the linked contract, which renewal alerts apply and whether purchase cost fields belong on the definition or in the financial module. Confirm the capacity list in your version, because the set of available capacities determines which records you can attach.
Certificates and expiry tracking
Servers and appliances that terminate TLS are the usual reason to link certificates to a custom asset. Enable the certificate capacity on the definition if those links must be recorded, and decide whether certificates attach to the device, the service it runs or both. Expiry alerts depend on the certificate records being maintained, so confirm the automatic action and notification settings in your version before you promise owners a warning date.
API and outbound webhooks
The system name you choose is the identifier that integrations call, and it cannot be changed after creation. Any script, REST client or webhook that filters or posts to the custom type will use that name, so agree it with the team that owns the integration. Test a read and a write against a non-production instance, and confirm the webhook payload fields for the custom type in your version.
Profile rights and access control
A new definition is not usable until profiles are granted access to it, so every role that creates, edits or reads these assets needs an explicit right. Map the custom type to your existing profiles, entities and groups, and decide which teams can see records across entities. Test access with a non-administrator account, since administrator access hides gaps in the rights model.
Directory sign-in and group mapping
Users reach custom assets only after they sign in, and the groups that come from LDAP, SSO or other external methods decide which profiles they receive. Confirm that the groups your directory provides can be mapped to the profiles that hold rights on the custom type. Review the authentication order and the fallback methods your deployment allows, because an account authenticated by a method you did not plan can receive rights you did not intend.
Questions teams ask before creating custom asset types
What drives the cost of creating custom asset types in GLPI?
The cost depends mostly on how many asset types you define, which capacities each one needs, and how much of your existing data must be mapped into them. Cost comes from three places: the time spent on the data model and profile design, the build and testing of each definition, and the handover to the people who will maintain it. Ask any partner for a quote that lists each asset type, its capacities, its profile rights and its data sources as separate lines, so you can see which items drive the total. Most of the work is one-time, while later changes to definitions, rights and integrations recur as your catalog grows.
How long does it take to set up custom asset definitions?
Duration depends on scope: the number of asset types, whether they need capacities such as contracts, software or network ports, and how many profiles must see or edit them. A small set of types with simple rights is a short piece of work, while a model that touches many profiles, existing records and integrations takes longer. Your written scope should state the timeline per deliverable, and you should ask for it to be checked against your change calendar. DeployOpen agrees timelines in writing before work starts, as part of a fixed-scope engagement.
What does our team need to provide before the work starts?
Plan to provide a named business owner for each asset type, a list of the attributes people actually record today, and examples of current records, including spreadsheets or exports. You also need the profiles and groups that will use the new types, a test GLPI instance that matches production, and access to the people who will create webhooks or API integrations. Confirm early who approves the system names, because those names are fixed after creation and will be used by development teams. Missing inputs at this stage are the most common cause of rework.
Can internal staff create custom asset definitions without a partner?
Yes, a team that already administers GLPI can create asset definitions, provided it has someone who understands profile rights and the data model. The harder part is the design decisions: choosing which types to create, naming them well, and deciding which capacities to enable. Teams that build alone often discover the cost of those decisions only after records and integrations depend on them. A partner can take on the design, build and handover, or review your design before you commit, and the split should be written into the scope.
Can we change the system name of a custom asset after creating it?
No. According to the GLPI documentation, the system name of a custom asset cannot be changed after it is created, and development uses it in API calls and webhooks. Choose a stable, lowercase name that describes the asset type rather than a department or project, because a rename later means a new definition, data migration and updates to every integration. Review the name with the developers who will call the API before you create the definition. You can read the official explanation in the GLPI documentation on asset definitions.
How do custom asset definitions differ from the Fields plugin?
Custom asset definitions create new asset types with their own lists, forms, rights and capacities, while the Fields plugin adds extra fields to existing item types. Use asset definitions when the thing you track is a different kind of asset, such as a separate server or laptop model with its own lifecycle. Use the Fields plugin when you only need a few extra attributes on items GLPI already manages. Check the current plugin and core feature set in your target version before deciding, because GLPI 11 changed how some forms and generic assets are handled.
What access controls must we configure for new asset types?
A new asset definition is not usable until profile access is configured, so every profile that needs to view or manage it must be granted rights explicitly. Plan rights by role, such as technicians who record assets, managers who review them and auditors who only read them, and test each profile with a real account. Also decide which entities can see each type, since entity visibility affects who sees records. Document the matrix as part of the handover, because it becomes evidence for access reviews later.
How DeployOpen scopes and delivers GLPI asset definitions
DeployOpen plans, builds, documents and supports GLPI custom asset definitions inside infrastructure you control. We start from the asset types your teams need, fix the system names and capacities before anything is built, and hand over a configured instance your own staff can operate.
How we scope
- We list the asset types you need, such as separate servers or laptops, and confirm which ones GLPI already ships.
- The written scope fixes each system name, which cannot be changed later, before any definition is created.
- Engagements are fixed-scope, so deliverables and timelines for asset definitions are agreed in writing before work starts.
How we build
- We attach only the capacities each asset type needs, such as software, network ports or contracts, and document why.
- We configure profile rights for each definition and test that the right groups can create, view and edit those assets.
- We check that API calls and webhooks use the agreed system names in a non-production instance before go-live.
How we hand over
- We deliver a written record of each definition, its system name, capacities, profile rights and the owner who approves changes.
- We walk your administrators through creating, retiring and reviewing asset types so the configuration stays in their hands.
- We document the decision between custom asset definitions and the Fields plugin for each data need, so future changes follow the same rule.
How we support
- Ongoing support, upgrades and testing are available as a retainer, which can cover checks after each GLPI version change.
- We review asset definitions when GLPI 11 or 12 is planned, confirming profile rights and integrations still behave as documented.
- Before any upgrade, we confirm with you which plugins need reactivation and which integrations depend on the system names.
