GLPI's permission system confuses most new administrators. Profiles, entities, recursive rights, dynamic assignment -- these concepts interact in non-obvious ways. This guide explains how the model works and walks through configuring a real user step by step.
Two dimensions: profiles and entities
Every permission in GLPI is defined by two axes:
- Profiles define WHAT a user can do -- view tickets, edit assets, manage users, access administration panels, approve changes. GLPI ships with default profiles (Super-Admin, Admin, Technician, Observer, Self-Service) that can be customized or extended
- Entities define WHERE a user can do it -- which organizational unit, location, or business division the permissions apply to. Entities are hierarchical: "Company" at the top, with child entities like "Bratislava," "Prague," "Remote"
A user with the "Technician" profile assigned in the "Bratislava" entity can view and edit tickets in Bratislava. They cannot see tickets in Prague unless explicitly given access there.
Recursive rights
When assigning a profile to a user in an entity, there is a checkbox: "Child entities." If checked, the permissions cascade down the entity tree. A technician assigned to "Company" with recursive rights can work in every child entity. A technician assigned to "Bratislava" without recursive rights sees only Bratislava-level data.
This matters for multi-site or multi-division deployments. The IT director might get Admin profile at the root entity (recursive), while regional technicians get Technician profile at their local entity only.
How profiles work internally
Each profile is a matrix of permissions across GLPI modules. For every object type (tickets, computers, software, users, etc.), you set one of these permission levels:
- No access -- the module is invisible to this profile
- Read -- view only
- Update -- can modify existing items
- Create -- can add new items
- Delete -- can remove items
- Purge -- can permanently delete (bypassing trash)
Permissions can also be scoped: "own tickets only," "group tickets," or "all tickets." A self-service user sees only their own tickets. A technician sees tickets assigned to their group. An admin sees everything.
Step-by-step: setting up a new user
Scenario: a new network technician joins the Bratislava office and needs access to tickets and network devices, but not servers or software management.
- Create (or import via LDAP) the user account under Administration > Users
- Clone the default Technician profile and name it "Network Technician"
- In the new profile, remove permissions for Computers and Software. Keep full access to Network Devices, Tickets, and Knowledge Base
- Go to the user's record, open the "Authorizations" tab
- Add: Profile = "Network Technician," Entity = "Bratislava," Recursive = No
- Save. The user can now log in and sees only network devices and tickets in Bratislava
Dynamic vs. static assignment
GLPI supports two ways to assign profiles:
- Static -- manually added per user, as described above
- Dynamic -- assigned automatically via rules. LDAP attributes, user groups, or email domains can trigger automatic profile and entity assignment. This is the preferred approach for organizations with Active Directory or other directory services, since new users get the right access without manual intervention
Common pitfalls
Three mistakes come up repeatedly: giving everyone Super-Admin "because it's easier" (this defeats the purpose of permissions and creates audit issues), forgetting recursive rights and wondering why child entity data is invisible, and creating too many custom profiles when entity-level separation would achieve the same result. Start with the default profiles, adjust permissions as needed, and only create new profiles when the access pattern genuinely differs.