GLPI supports multi-entity deployments where a single instance serves multiple subsidiaries, departments, or client organizations. This is a convenience feature for administration, but it is also a security feature. Entity boundaries in GLPI control who can see which tickets, assets, knowledge base articles, and configuration items. Done right, entity isolation enforces the principle of least privilege at the data level. Done wrong, it leaks sensitive information across organizational boundaries.
How entities create data boundaries
Every object in GLPI belongs to an entity. A ticket created in Entity A is invisible to users who only have profiles assigned to Entity B. The same applies to computers, software licenses, contracts, knowledge base articles, and virtually every other object type. This is not just a UI filter — the database queries enforce entity boundaries, so there is no way to bypass them through direct URL manipulation or API calls.
This makes entities the primary mechanism for data isolation in multi-tenant or multi-department GLPI deployments.
Recursive vs. non-recursive visibility
GLPI entities are hierarchical. A parent entity can have child entities. When you assign a user a profile on a parent entity with recursive rights, they can see data in all child entities below it. When you assign a profile without recursion, they see only the data in that specific entity.
This distinction matters more than most administrators realize.
When recursive makes sense
A central IT team managing service delivery across all subsidiaries needs recursive access on the root entity. A group manager who oversees multiple regional teams needs recursive access on their region’s parent entity. These are legitimate use cases.
When recursive causes problems
Giving a first-line technician recursive access on the root entity means they can see every ticket in the system — including HR-sensitive requests, executive IT issues, or client data from other subsidiaries. This is a common misconfiguration, usually caused by convenience during initial setup that never gets cleaned up.
Auditing access: who sees what
GLPI provides the tools to audit entity access, but you have to know where to look.
- Go to Administration > Users, select a user, and check the "Authorizations" tab. This shows every profile-entity pair assigned to that user, including whether each assignment is recursive.
- For a broader view, go to Administration > Profiles, select a profile, and look at the "Users" tab to see everyone who holds that profile and in which entities.
- The GLPI REST API can also extract this data programmatically:
GET /apirest.php/User/{id}/Profile_Userreturns all profile assignments for a user.
Run this audit quarterly. Look specifically for users with Super-Admin or admin-level profiles assigned recursively on the root entity. In most deployments, this list should be very short — two or three people at most.
Common mistakes and how to fix them
Everyone gets the same profile
Some deployments create a single "Technician" profile and assign it everywhere. This means every technician can do everything — create changes, delete assets, modify rules. Instead, create tiered profiles (L1 Agent, L2 Specialist, Team Lead) with different permission sets, and assign them only to the entities where each person works.
Self-service users see too much
End users who log tickets should only see their own tickets and the knowledge base articles published to their entity. Check the Self-Service profile and verify that "See all tickets" is set to No and that entity assignment is non-recursive.
No regular access review
People change roles. Contractors leave. Subsidiaries get reorganized. Without periodic review, profile assignments accumulate and drift from the actual organizational structure. Set a calendar reminder or — better — create a recurring GLPI ticket assigned to the admin team to review access rights every quarter.
Entity isolation as a compliance requirement
For organizations operating under ISO 27001, NIS2, or GDPR, data isolation is not optional. If your GLPI instance holds ticket data that includes personal information (employee names, contact details, incident descriptions), entity boundaries are part of your access control framework. Being able to demonstrate that data from Entity A cannot be accessed by users in Entity B is something auditors will ask about.
GLPI’s entity model gives you the mechanism. The configuration is what determines whether it actually works.