The pitch for using GLPI outside IT is easy: HR has requests, facilities has requests, finance has approvals — they're all tickets, so put them in the same system. The part that doesn't get talked about is how GLPI actually isolates those teams from each other, because without isolation you have a shared mailbox with categories, not a cross-functional service desk. That isolation layer is called entities, and getting it right is most of the work.
What an entity actually is
In GLPI, an entity is a scope boundary. Categories, SLAs, assignment groups, notification templates, knowledge base articles, and ticket visibility all live inside one. A user in entity IT doesn't see tickets from entity HR unless you explicitly grant them a profile in HR too. Reports and searches scope to the entity you're currently looking at. It's not tagging or filtering — it's a hard wall the permission system enforces. Once you understand that, the "GLPI for everything" question stops being "can it?" and becomes "where do the walls go?"
What you get when it's set up well
A shared install done right buys three things no department could get on its own:
- One login, one URL, one inbox icon in the browser. Users don't learn three tools to submit three kinds of requests; the portal shows them the forms that belong to their entity and nothing else.
- One admin team instead of three. Backups, upgrades, SSO, the mail catcher, the plugin inventory — maintained once. The per-department cost of running a ticketing system drops substantially.
- Cross-entity reporting for leadership. The CFO or COO can get a single view across IT, HR, and facilities without pulling three spreadsheets. GLPI's recursion settings control exactly which roles can see across and which cannot.
The decisions to make before you start
Multi-entity designs fail when they're drawn on the whiteboard in an afternoon. The questions worth taking seriously upfront: are your entities functional (IT / HR / Facilities) or geographic (Bratislava / Košice / Vienna), and if both, which is the parent? Which categories should live at the root (visible everywhere) versus inside one entity (HR-only, for example)? Who needs cross-entity visibility for reporting, and who needs it for actually working tickets? And — the one most commonly skipped — who owns the root-level configuration when every department wants a seat at the table?
Where it goes wrong
The two failure modes we see most. First, "one entity for everything, we'll filter later." This always ends with permission leaks and an HR director seeing IT tickets about her own laptop. Retrofitting entity boundaries after six months of data means remapping every ticket. Second, deep entity trees built before anyone has real traffic. Five levels of nesting looked like good future-proofing in the design document; in practice, users can't find their forms, reports double-count, and nobody remembers which level the SLA actually applies at. Start shallow.
Where to start
Pick two departments — usually IT and one other, whichever one is most frustrated with the current setup. Create them as siblings under the root. Get the categories, groups, and SLAs right for both. Let the install run for six to eight weeks with real traffic before adding a third. By the time you've doubled, you'll know whether your boundary decisions hold or need to change, and the cost of fixing them is still small.