Entities and locations are the organizational foundation of GLPI. Configuring them correctly from the start avoids massive rework later. This guide shows the best practices.
Entities: data segmentation
Entities divide GLPI into compartments. Each entity can have:
- Its own tickets, assets, and users
- Independent business rules
- Specific SLAs and calendars
- Custom CSS (visual identity)
- Own email notifications and templates
When to use entities
- Company with branches: each branch as an entity
- MSP provider: each client as an entity
- Independent departments: IT, HR, Facilities as separate entities
Hierarchy
Entities are hierarchical (parent-child). The root entity contains all others:
Company (root)
├── São Paulo HQ
│ ├── IT
│ └── HR
├── Rio de Janeiro Branch
│ ├── IT
│ └── HR
└── Curitiba Branch
Inheritance
Rules, SLAs, categories, and templates can be inherited from the parent entity. This avoids duplication: configure once at the root and all children inherit.
Locations: physical spaces
Locations represent where things are physically:
- Buildings, floors, rooms
- Data centers, racks
- Addresses, cities, states
Unlike entities, locations do not segment permissions. They are only geographic references.
Typical structure
São Paulo
├── Building A
│ ├── Floor 1
│ │ ├── Room 101
│ │ └── Room 102
│ └── Floor 2
└── Data Center
├── Rack 01
└── Rack 02
Best practices
- Plan your entity structure before you start registering data
- Use entities for access control, locations for physical organization
- Don't create too many entities – each one adds administrative complexity
- Take advantage of inheritance: configure rules and SLAs at the root entity
- Use locations with coordinates to integrate with the Geolocation module
Next step
With entities configured, define profiles and permissions and configure business rules per entity.