How GLPI inventory rules control what lands in your asset database
GLPI inventory rules decide where each device that reports to GLPI ends up: which entity owns it, whether it is created as a new asset, whether it is merged with an existing record, whether it is refused, and what type it becomes. Without deliberate rules, a rollout of GLPI Agent to thousands of machines can fill the database with duplicates, assets in the wrong entity or types nobody wanted to track. The GLPI Inventory plugin provides the rule engine that evaluates each incoming inventory document against an ordered list of criteria and actions, while the GLPI Agent on each machine collects the hardware and software data and sends it to GLPI. The agent decides what it sees; the rules decide what GLPI keeps.
Rule order matters because the engine evaluates rules in sequence and the first matching outcome shapes the result, so a broad rule placed above a specific one can silently override it. Teams should write down the entity assignment logic, the matching keys used to recognize a returning device, the conditions for refusing devices and the mapping from detected types to custom asset definitions before the first agent reports. Confirm in your own test instance how the plugin version you run orders and applies rules, and check which criteria it supports for your agent version, since rule behavior is tied to the plugin release. Plan a test group of machines, review the resulting records, and only then widen the deployment.
The agent and the plugin have distinct jobs, so troubleshooting starts by asking which side produced the problem. If a machine's data is wrong or missing, look at the agent's collected content and its server communication first. If the data arrives but lands in the wrong entity or type, the fault sits in the rules on the GLPI side. Keeping both sets of settings under version control, along with a list of test devices and expected outcomes, gives your team a repeatable way to check changes before they reach production.
Inventory rule options and when each fits
This table compares the main outcomes an inventory rule can produce when agent data reaches GLPI: entity assignment, location and type assignment, refusing or ignoring a device, and transforming a detected type into a custom asset definition. Read each row as a decision: when the outcome fits, what it changes in the asset record, and the main risk to test before enabling it on a production fleet.
| Outcome | When it fits | What it changes in the asset record | Main risk |
|---|---|---|---|
| Entity assignment | Several business units or customers share one GLPI instance and their devices must be visible only to their own entity | Sets the owning entity of the imported computer, so profile visibility follows the entity tree | A broad or misordered criterion can place devices in the wrong entity, and visibility then follows the wrong tree |
| Location and type assignment | Devices arrive without a usable site or category, and you want consistent location and type fields from network or hostname patterns | Sets location and type on the imported item, which feeds dashboards, reports and later rules | Rules matching on weak data such as generic hostnames can mislabel assets that later rules then trust |
| Refusing a device | Agents report hosts that should never enter the asset inventory, such as test machines or devices you have excluded by policy | Blocks the import so no asset record is created from that inventory report | Refused data can hide genuine assets if the match is too wide, and refusal is harder to spot than a visible error |
| Ignoring a device | A discovered or reported device is not yet approved, and you want to hold it without losing the record | Keeps the device out of the managed inventory until someone reviews it and promotes it | Ignored items can accumulate unreviewed, so the backlog needs a named owner and a review routine |
| Transforming a detected type into a custom asset definition | Hardware such as specialized equipment is detected under a generic type, and your team tracks it as a defined custom asset | Creates an item of the custom asset type instead of the default type, with its own fields and lifecycle | Existing records and reports tied to the default type may not follow the change, so test history and reporting first |
| Rule order | Several rules may match the same device, and the outcome depends on which rule runs first | Determines which fields are set and whether a later rule can still change them | An earlier broad rule can prevent a later specific rule from applying, which is hard to diagnose after the fact |
Assigning entities and organizational boundaries
Entity assignment decides which organizational unit owns each imported device, and that ownership later controls who can see and change the record. The cards below cover the decisions to settle and the criteria to route on before any import rule is written.
Agree the entity tree first
Before writing any rule, settle the entity hierarchy that GLPI will use: countries, business units, sites or departments. Each rule that assigns an entity points at one node in that tree, so a renamed or missing entity breaks every rule that references it. Ask the business owners to approve the tree in writing, including who owns each top-level entity and whether sub-entities will inherit visibility from their parents.
Choose a naming convention
Decide how entity names, tags and rule names will be written so that engineers can read a rule list and understand it months later. A consistent pattern for site codes, country codes and team prefixes makes it easier to audit which rule placed a device and to spot duplicates. Document the convention alongside the rule export so that new administrators follow the same scheme.
Pick the routing criteria
Decide which signals will place a device: the network range or subnet the agent reports, the Active Directory domain or computer OU, the tag set during agent deployment, or a combination. Each signal has a different failure mode. Subnets change when sites move, domain membership can be inconsistent on workgroup machines, and tags depend on the deployment script being correct. Test each criterion against a sample of real machines before relying on it.
Define the fallback entity
Every device that matches no rule still needs a home. Create a fallback entity that is visible only to the inventory team, and confirm that unmatched devices land there rather than in a business unit that did not claim them. Review the fallback queue on a fixed schedule, because a growing fallback entity usually means a routing rule has broken or a new site has been added without a rule.
Map entity placement to access
An entity placement is also an access decision. Profiles and users in a parent entity see child entity assets, while users in a sibling entity do not, so a device placed in the wrong entity can expose its record to the wrong team. Before go-live, confirm with the security owner which profiles will see which entities, and test with a non-admin account that a device from one business unit is hidden from another.
Set rules for devices that move
Laptops change sites, and servers can be reassigned between teams. Decide whether a later agent report should move an asset to a new entity or leave it where it was first placed, and who approves a manual move. If automatic moves are allowed, document which criteria can trigger them so that a single DHCP or VPN change does not silently transfer ownership of an asset.
Building and testing inventory rules before rollout
This sequence moves GLPI inventory rules from a documented baseline to a tested configuration. Each step ends with a check, so the rule set reaches the full fleet only after a pilot group has produced the asset records you expected.
Confirm GLPI version and Inventory plugin status
Record the GLPI version, the PHP and database versions, and the state of the GLPI Inventory plugin on the instance you will test against. Confirm that the plugin is active and that its version is compatible with the GLPI release. If you have just completed a major update, reactivate the plugin, because since GLPI 11.0 plugins are suspended after a new version is detected. Done when the version record, plugin status and a successful test of an agent connection are saved in your change record. Ask DeployOpen or your own team to confirm the plugin compatibility matrix for your exact release before you go further.
Export or document current rules
Export the existing inventory import and entity assignment rules, or write them down in a table with each rule's criteria, action, order and owner. Keep a copy of the database and the configuration directory before you change anything, so a rule set can be restored if a test goes wrong. Done when you have a rule inventory file stored outside the production instance and a short list of rules that you plan to keep, change or retire.
Define a test entity
Create a separate entity in GLPI for test data, and decide how devices from the pilot group will be routed into it. Use a naming convention that makes test records easy to find and remove later. Limit who can see and edit the test entity through profiles and entity access. Done when the test entity exists, a rule can route a device into it, and a non-test administrator cannot see its contents by accident.
Create rules in a defined order
Build the rules in the GLPI rule engine in the order you documented, starting with the rules that refuse or ignore devices, then entity assignment, then the rules that transform detected types into custom asset definitions. Test each rule's criteria against a sample device record before saving the next one. Done when the rule list shows the intended order and each rule has a written purpose that matches its position in the sequence.
Run inventory from a small pilot group
Select a small group of agents, with a mix of Windows, Linux and macOS hosts where possible, and trigger an inventory run for them. Include at least one device that should be refused and one that should be transformed into a custom asset type. Done when each pilot device has reported at least once and the GLPI task or log shows which rules matched, with no unexpected errors.
Check the resulting asset records
Open each pilot asset in GLPI and compare the entity, asset type, name, serial number and key fields with the expected results in your rule table. Check that refused devices did not create asset records and that duplicates were not created for devices that already existed. Done when every pilot device matches its expected outcome, and any mismatch is traced to a specific rule and fixed before the rule set moves to production.
When to refuse devices and when to convert detected types
The first decision is whether a detected device should ever become an asset. Refusing a device in the GLPI Inventory rules means the agent data is discarded at import, so no asset record, history or relation is created. Converting a detected type means the record is kept and written into a custom asset definition instead of the standard hardware type. Refusal suits devices that are out of scope for your inventory, such as personal equipment, test lab noise or guest devices. Conversion suits hardware your organization owns and tracks but that GLPI would otherwise classify poorly. Before you write either rule, confirm in your own GLPI version exactly which actions the rule engine offers, because the labels and available outcomes differ between releases and you should not assume them from older documentation.
Silent dropping is the main risk. A refusal rule that matches too broadly removes hardware from the inventory without any visible error, and the gap only surfaces during an audit, a license count or an incident. Keep refusal rules narrow, tie each one to a documented reason, and review the rule's match criteria whenever agents or network ranges change. Preserve an audit trail by logging the rule name, the matched fields and the decision for every refused or converted record. Confirm with your own team which log channel, retention period and review owner will hold that evidence, since the required retention depends on your policies and any framework you are preparing for. Test rules against a sample of real agent payloads in a non-production entity before they touch the live inventory.
Conversion is where this section meets the custom asset types workstream. This section covers only the import decision: which detected records are transformed, which rule performs the transformation, and how the original detection is kept traceable. The definition of the custom asset type itself, its fields, layouts and lifecycle, belongs to that workstream. Agree on the mapping between detected attributes and custom asset fields with the owner of the asset model before building rules, and record that mapping as a controlled document. Any change to the asset definition later can alter how existing rules behave, so treat the two as one change-controlled set of configuration.
Security and operational risks of inventory rules
Inventory rules decide which entity, state and type every discovered device receives, so a single mistake can move or hide many records at once. The cards below cover the risks that matter most for GLPI inventory rules and the controls that keep them manageable.
Overly broad rules move records
A rule that matches on a loose criterion, such as a common hostname pattern or a generic manufacturer string, can assign large numbers of computers to the wrong entity. Once records sit in another entity, visibility and profile permissions change with them. Before enabling a rule, test its criteria against a sample of real agent payloads and confirm how many existing assets it would touch. Use narrow match criteria and review the entity assignment order before saving.
Rules that hide devices
A refusal or ignore rule removes a device from normal view, so an unexpected match can keep a machine out of security review without any alert. Devices such as unknown laptops or servers may then never appear in the asset list that auditors and responders use. Review every refusal rule on a schedule, and check the list of ignored or refused devices for entries that should be managed assets. Keep the reason for each refusal documented in the rule description.
Rule changes without change control
Rule order and criteria behave like code: a small edit to a priority or a condition can change the outcome for every future inventory run. When changes are made directly in the web interface by several administrators, nobody can explain why an asset type or entity changed. Store each change request with its owner, test evidence and approval, and record the rule export before and after the change. Ask whether your team can roll back a rule set to a known state.
Backups before rule changes
Rule changes that reprocess or reassign existing data are hard to reverse by hand, so the database is the only complete record of the prior state. The GLPI config directory and the key files glpi.key and glpicrypt.key must be backed up with it, because encrypted fields cannot be read without them. Take a database and file backup immediately before a rule set change, and confirm that a restore has been tested on a copy of the instance.
Unreviewed transformations of asset types
Converting a detected type into a custom asset definition changes how records are stored, searched and reported. A mapping that looks correct for one model may misclassify similar hardware, and reports built on the old type can silently miss the new records. Test each type mapping against a representative set of devices, and review existing dashboards and saved searches before the change goes live. Document which custom definitions are owned by which team.
Unchecked rule ownership and access
Anyone who can edit inventory rules can change where data goes, which makes rule administration a privileged function. If the profile that manages rules is granted to general administrators or to several support staff, the change path is broader than the security team expects. Limit rule editing to a named group, review that profile assignment during access reviews, and confirm that step-up authentication is enabled for administrative actions on your GLPI version.
Questions teams ask before building GLPI inventory rules
How long does it take to design GLPI inventory rules?
Design time depends mostly on how many device types, sites and naming conventions the rules must cover, and on how clean the data arriving from agents already is. A small estate with one entity and a handful of device classes needs far less design than a multi-entity organization that must route laptops, servers, printers and network gear into different asset types. No duration figure is supplied for this work, so ask any partner for a written scope that lists the rule groups, entities and asset types covered, and confirm the review rounds needed with stakeholders before work starts. Test imports on a copy of real agent data before anything touches production assets.
What does it cost to build GLPI inventory rules?
The cost has three parts. Your internal staff spend time providing sample data, approving entity and naming decisions, and reviewing test results. A partner, if you use one, is paid for the scope written in the agreement, which should name the rule groups, asset type definitions and test cycles. GLPI itself is open source under the GNU General Public License version 3, so the software has no license fee. If you choose a GLPI Network subscription, the published rates are 19 euros per user per month for public cloud and 21 euros per user per month for private cloud with a 25-user minimum, and self-hosted subscriptions run from 100 euros per month (Basic) to 4,500 euros per month (Enterprise), according to GLPI's subscriptions page. Those subscriptions are optional for rule design. Ask any quote to separate one-time build work from recurring support.
Can our own team build GLPI inventory rules without a partner?
Yes, if you have an engineer comfortable with GLPI administration, the rule engine and a test instance. The rule engine is configured in the GLPI interface, and the work is mostly careful ordering, testing and documentation rather than custom code. The risks are predictable: rules that overlap, a device refused by a broad rule, or entity assignments that quietly send assets to the wrong part of the organization. A partner adds value when you need an independent review, a faster first pass, or help defining asset types for a large estate. Decide early who owns the rules after handover, because rule sets change with every new site or device class.
What inputs do we need to provide before rule work begins?
Start with a sample export of agent data from representative devices, covering each operating system, device class and site you manage. Next, provide your entity structure, the naming standard for manufacturers, models and asset types, and a list of devices that must never enter the inventory, such as test machines or home equipment. Decision makers must also approve who may change rules and how changes are reviewed. Ask for these inputs in writing as part of the scope, because missing sample data is the most common reason rule design stalls. If you have existing GLPI assets, include a record of how they were created so rules do not duplicate them.
How do GLPI inventory rules change after an upgrade?
Rules are stored in the database, so they survive a version upgrade, but each upgrade should be treated as a test event. Back up the database, files and the config directory, including glpi.key and glpicrypt.key, before replacing application files and running php bin/console db:update. Since GLPI 11.0, plugins are suspended after a new version is detected and must be reactivated after major updates, so check that the inventory plugin is active and that its rules still match the agent data it receives. Re-run a sample import after each upgrade. Confirm the exact steps for your version in the GLPI update documentation before you schedule the change.
Which engineering checks catch rule mistakes before production?
Test rules against a copy of the database and a set of recorded agent inputs that cover normal and unusual devices. Check the rule order first, because an early rule that matches too broadly can refuse or reassign devices before later rules run. Verify entity assignment for each site, confirm that each custom asset type receives the expected fields, and look for duplicate records after a second inventory run. Keep a change log with the reason for each rule, so an auditor or a new administrator can trace why a device ended up where it did. Document the test results before you enable rules in production.
Do inventory rules affect our compliance evidence?
They can. Inventory records are often used as evidence for asset inventory controls, so an incorrect rule can produce records that look complete but are wrong. Rules that refuse or reclassify devices change what the inventory shows, so each change should be approved and logged. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports or certifications, and independent auditors make that determination. Ask your auditor which inventory fields they expect to see and confirm that your rule documentation supports those fields.
How DeployOpen scopes and delivers GLPI inventory rules
DeployOpen delivers GLPI inventory rules as a fixed-scope engagement in your own infrastructure, with the scope, deliverables and timeline agreed in writing before any rule is changed. The written scope lists the device sources in play (agent inventory, discovery results, any cloud or virtualization feeds), the entities that must receive each source, the asset types you need to keep, and the devices that must be refused or quarantined. A quote follows from that document, so the more precisely your team describes the data it wants and the data it does not want, the more predictable the price and the schedule will be. Confirm during scoping who on your side approves rule changes and who owns the GLPI instance after handover.
The design work starts with a rule design workshop. Your asset owners, network team and GLPI administrators walk through sample inventory payloads from real agents and discovery tasks, then decide the order in which the rule engine should evaluate import, entity assignment, refusal and type transformation rules. Each rule gets a stated purpose, a test case and a named owner. DeployOpen then runs a pilot on a limited set of machines or a single site, compares what GLPI stores against what was expected, and adjusts rule order or conditions before wider rollout. Ask the delivery team to show the pilot results, including any devices that matched an unexpected rule, because those are the cases that cause silent misclassification later.
The engagement closes with documentation of the final rule order, the reasoning behind each rule and the rollback steps if a change misfires, plus a handover session with the staff who will maintain the rules. Check that the documentation names the GLPI version it was tested on, since rule behavior can change across the GLPI 11 and 12 releases. Store the exported rule set and the configuration backup alongside your change records so that future changes can be reviewed against a known baseline. Ongoing support and rule reviews after handover can be scoped as a separate retainer if your team wants DeployOpen to keep testing new device sources.
