Entity-based RBAC in GLPI: separating access across teams and clients

GLPI solves two access problems at once. Profiles say what a user is allowed to do — create tickets, approve changes, edit assets. Entities say where they're allowed to do it — which organizational unit, department, or even which client. Without entities, every user sees every ticket and every asset. This article assumes you know the basics of profiles; if not, start with profiles and permissions in GLPI.

When entities make sense

Three typical scenarios where entities are essential:

• Large organization with autonomous departments — the IT team for the Bratislava office shouldn't see tickets from the Prague office. Each runs its own helpdesk, but uses the same GLPI instance.
• MSP serving multiple clients — your team operates GLPI for ten different clients. Client A must not see Client B's tickets, but your service team sees them all.
• Holding-company structure — the parent company sees subsidiaries' data for consolidated reporting; subsidiaries see only their own data.

Entity hierarchy

Entities in GLPI form a tree. The Root entity is always at the top. Below it, you build a hierarchy as deep as you need:

Root entity
├── Bratislava
│   ├── IT
│   └── HR
├── Prague
│   ├── IT
│   └── HR
└── Clients
    ├── Client A
    └── Client B

Tickets, assets, users, and almost every object in GLPI belong to a specific entity. That alone determines who sees them.

Recursive vs non-recursive rights

This is the most common source of confusion. When you assign a profile to a user in an entity, you choose whether the profile applies recursively (also in child entities) or not.

Example: a regional manager in Bratislava has the Manager profile assigned in entity "Bratislava" recursively. They see tickets in "Bratislava", "Bratislava → IT", and "Bratislava → HR". By contrast, a helpdesk technician has the Technician profile in "Bratislava → IT" non-recursively — they see only IT tickets, not HR.

Practical rule: recursive rights for leads and managers, non-recursive for specialists.

One user, multiple roles

The same user can hold different profiles in different entities. This is powerful but often overlooked:

• Maria is Team Lead in her home entity "Bratislava → IT".
• Maria also holds Observer read-only access in "Prague → IT" — she needs to see those tickets for coordination, but cannot edit them.
• Maria has no access to "Clients" — external tickets aren't her concern.

At login Maria selects which entity she's currently working in. GLPI applies the profile matching that entity.

The MSP scenario in practice

The most common multi-tenant entity setup looks like this:

1. Create sub-entities for each client under a dedicated "Clients" entity (e.g., "Clients → ABC s.r.o.").
2. Assign client users (requesters) to their client entity with the Self-Service profile. They see only their own tickets.
3. Your service team gets the Technician profile in the "Clients" entity recursively — they see tickets across all clients.
4. In Setup → Mail collectors, route by destination email address: tickets arriving at client-abc@your-helpdesk.com automatically land in entity "Clients → ABC s.r.o.".
5. SLAs, categories, and ticket templates can be defined per entity — each client has its own configured to its contract.

Dynamic assignment via LDAP

When deployed with LDAP or Active Directory, you don't need to assign entities manually. In Setup → Authentication → LDAP directories you specify an LDAP attribute (such as department or memberOf), and in Administration → Rules → Rules for assigning a user to an entity you map its values to specific GLPI entities.

Example: if memberOf=CN=IT-Bratislava,..., assign the user to "Bratislava → IT" with profile Technician. On the next login the rule applies automatically — no admin intervention.

Common mistakes

Hierarchy too shallow

You start with "Bratislava" and "Prague", a year later you add "Brno", "Košice", "Clients", "External vendors" — and realize you need sub-departments. Plan the entity structure at least one level deeper than today's needs; adding a sub-entity later is easy, but moving tickets between entities is manual work.

Forgotten recursion

A manager with non-recursive rights at the top entity sees only tickets attached directly to it, not those in sub-entities. After a reorg, this often gets forgotten and the manager stops seeing their team's data — usually surfacing for the first time at the next reporting meeting.

Client sees client

The worst-case for an MSP. A misconfigured recursion can let users from Client A see tickets from Client B. Always test from the user's perspective using the Test button in the profile screen, or by logging in with a test account — never roll a multi-tenant deployment to production without that check.

When entities aren't enough

Entities separate data, but they don't separate configuration. Plugins, business rules, and some global settings apply across all entities. If you need fully isolated environments (for example, regulatory separation between healthcare and finance arms of a holding), consider separate GLPI instances rather than multi-tenant in one.

For most organizations entity-based RBAC is sufficient — the combination of entities, recursive rights, and per-entity profiles handles the typical access scenarios you'll meet in practice.