A holding company with five subsidiaries. A government agency with regional offices. An IT outsourcing provider with ten client organizations. All of them need separate helpdesks — different users, different SLAs, different visibility rules — but nobody wants to run five separate GLPI installations.
GLPI's entity system solves this. One GLPI instance, multiple independent helpdesks, centralized administration.
What entities give you
An entity in GLPI is an organizational boundary. Each entity can have its own:
- Users and groups — users in Entity A can't see tickets from Entity B
- Ticket categories — each entity can have a category tree tailored to its services
- SLA rules — different response and resolution times per entity
- Notification templates — branded emails with entity-specific sender address and logo
- Asset inventory — assets belong to an entity and are only visible within it
From the end user's perspective, each entity feels like a standalone helpdesk. From the admin's perspective, it's one system with one database, one upgrade path, and one configuration to maintain.
Typical multi-entity setups
Holding / group of companies
Root entity = corporate IT. Child entities = subsidiaries. Corporate defines shared policies (password reset process, hardware procurement workflow). Subsidiaries customize their own categories and SLA targets. Reporting rolls up — the CIO sees aggregate metrics, subsidiary IT managers see their own.
IT outsourcing
Root entity = the MSP's internal operations. Child entities = client organizations. Each client's users log into the same GLPI URL but see only their own helpdesk. The MSP's agents can switch between entities to handle tickets from different clients. Billing reports are generated per entity.
Government / public sector
Root entity = ministry or central authority. Child entities = subordinate agencies or regional offices. Central entity sets governance rules and audit requirements. Regional entities handle local support with local teams. Cross-entity escalation routes difficult issues to central specialists.
Configuration essentials
Entity-specific mail collectors
Each entity can have its own email address for ticket creation. support@subsidiary-a.sk creates tickets in Entity A, helpdesk@subsidiary-b.sk creates them in Entity B. GLPI's mail collector rules route incoming email to the correct entity based on the recipient address.
Shared objects
Some things should be consistent across entities — ticket categories for company-wide services, knowledge base articles about shared systems, notification templates for standard communications. GLPI lets you create objects in the root entity and share them downward to child entities. Children inherit but can't modify the parent's objects.
Cross-entity ticket visibility
By default, entities are isolated. But you can grant specific groups visibility across entities. A central network team that handles infrastructure for all subsidiaries needs to see tickets from every entity that involve network issues. This is configured through profile permissions — recursive visibility down the entity tree.
When single-entity is enough
Not every organization needs entities. If you have one IT team, one set of users, and one set of SLAs — a single root entity works fine. Entities add complexity: permission design, category inheritance, cross-entity reporting. The rule of thumb: if you'd otherwise consider running two separate GLPI instances, use entities instead. If you wouldn't, don't.