When GLPI entities fit a multi-site organization or MSP
Entities are GLPI's construct for separating data and delegating scope inside one instance. If your organization runs several sites, subsidiaries or managed clients on a single GLPI installation, the question is whether those units should each sit in their own entity or share one tree and be distinguished by groups and locations. Entities control which assets, tickets, contracts and users a given profile can see and act on, and they are the unit you assign when you delegate administration. The GLPI documentation describes entities as a hierarchy, so a parent entity can see into its children when a profile is granted recursive access. Confirm the exact visibility rules for your GLPI version in the official documentation before you design around them, because they determine whether a regional administrator can see a parent's records.
The core trade-off is isolation and delegation on one side, administrative overhead and query cost on the other. Each entity you add is one more place to define profiles, rules, notifications and reports, and a deep entity tree adds work to every permission check and list view, which affects how the instance performs under load. Groups and locations are lighter tools. They organize people and places for routing and reporting but do not, on their own, fence off data from another unit. As a rule of thumb for planning, ask whether a unit needs its own administrators or its own data boundary. If it does, it probably needs an entity. If it only needs its own queue or its own location label, it probably does not.
The rest of this page works through that decision: how to model entities against groups and locations, how to isolate clients or divisions, how to delegate administration without weakening the Super-Admin profile, and what a deep tree costs in performance. Before you commit, measure your planned entity count, the number of assets and tickets per entity and how many administrators you expect to delegate to, and test those numbers on a staging instance built on a version you have confirmed for your environment.
Entity patterns for divisions, clients and sites
A single organization with divisions usually needs one entity tree that mirrors how the business is run: a root entity for the company, then child entities for divisions such as finance, operations or a regional business unit. Users in a division see their own assets, tickets and contracts, while the central IT team, placed at the root, sees everything below it. This keeps one shared catalog and one set of rules while still separating records that belong to different budgets or owners.
- Root and child roles: Keep the root for central IT and the security team, and create child entities only where a division needs its own visibility or approvals.
- Recursive visibility: Profiles assigned at a parent entity can reach child entities when recursive assignment is enabled, so confirm which profiles should inherit access downward.
- Groups and locations: Use groups for teams that cut across divisions and locations for physical places, so the entity tree stays shallow.
- Division changes: Reorganizations move people and assets between divisions, so ask how often divisions change and how assets will be transferred.
- Reporting: Decide whether division heads need their own dashboards or whether central reporting is enough.
Before committing, confirm the division list with the business owners, the expected number of levels, and which teams must never see each other's tickets.
A managed service provider usually places each client company under its own entity below a provider root, so that one GLPI instance serves many customers without exposing their records to each other. The provider's technicians sit at the root or in a provider entity with broad rights, while client users are assigned to their own entity with narrow profiles. This is the pattern where entity isolation is most important, because a misassigned profile can expose one client's inventory to another.
- Provider root: Hold provider-owned settings, shared knowledge and technician accounts at a root entity that clients cannot reach.
- One entity per client: Give each client company its own entity so that assets, contracts and tickets stay separated by default.
- Client-side administrators: Some clients want their own administrators, so decide whether those users get a limited profile inside their entity only.
- Shared services: Software catalogs or standard templates that apply to all clients can live at the root, but check that they do not expose client data.
- Billing and contracts: Contracts and financial records follow the entity, so confirm that the billing workflow matches the entity boundaries.
Confirm with legal and security owners how isolation must be demonstrated to each client and whether any client requires its own instance rather than an entity.
An enterprise with one legal entity and many sites usually gains little from a deep entity tree. In most cases a single entity for the company, with locations representing sites and groups representing functional teams, keeps administration simple and avoids duplicate configuration. Entities become useful here only when a site must be administered separately, for example when a remote subsidiary runs its own IT team under the same legal umbrella.
- Locations for sites: Model each building or site as a location so that assets and users can be filtered by place without adding entity levels.
- Groups for teams: Use groups for helpdesk teams, field technicians or on-call rotations that span several sites.
- Entities for autonomy: Add a child entity only when a site needs separate rules, approvals or administrators.
- Asset moves: Plan how equipment moves between sites, since location changes are easier to manage than entity changes.
- Single view: Keep one root entity when executives need a consolidated view across all sites.
Confirm whether any site needs its own administrators or approval rules, and whether reporting must be consolidated or split by site before the tree is designed.
Entity design options and when each fits
This table compares three ways to shape GLPI entities: a flat set of sibling entities, a nested tree with recursive assignment, and separate GLPI instances per client. Read each column to see what isolation you get, what administration costs, how reporting works across scopes and where the design usually breaks. The main takeaway is that entities separate data within one instance, while separate instances are the only option that separates the platform itself.
| Option | Isolation achieved | Administrative effort | Reporting across scopes | Main risk |
|---|---|---|---|---|
| Flat sibling entities | Data separated per entity; all entities share one database, one set of plugins and one upgrade cycle | Low to moderate; one administrator model and few profile variants | Straightforward when each report targets one entity or the root | Entities multiply without a naming or ownership rule, and unrelated teams end up sharing profiles |
| Nested entity tree with recursive assignment | Parent profiles can see child entities, so access follows the hierarchy rather than separate silos | Moderate to high; every profile and recursive grant needs review as the tree grows | Strong for consolidated views from a parent entity, since child data rolls up | Over-broad recursive access exposes client data to staff who only needed one branch |
| Separate GLPI instance per client | Strongest separation: own database, files, plugins, keys and administrators | High; each instance needs its own upgrades, backups, monitoring and plugin reactivation | Weak; cross-client reports need an export or a separate reporting layer | Upgrade and patch drift across instances, and duplicated cost of running each one |
| Groups or locations instead of entities | None for data access; groups and locations describe records but do not restrict them | Low | Simple to filter, but not a control boundary | Teams assume a group hides data from users who can see the entity |
| Flat design with per-client profile templates | Entity separation kept, with profiles copied per client to limit grants | Moderate; template changes must be reapplied to every client profile | Good for per-client reporting within one entity | Template drift over time leaves some clients with grants others do not have |
Delegating administration across entities with profiles
In GLPI, what a user can see and change is decided by two assignments working together: the profile they hold and the entity they hold it in. A technician with a broad profile assigned to one client entity can only act on that client's tickets, assets and contracts, while the same profile assigned at the root entity reaches everything beneath it. For a multi-site organization or an MSP, the practical decision is therefore not only which profiles exist but where each profile assignment sits in the entity tree. Map each administrator group to a profile and an entity pair on paper before you create any accounts, and check that every pair gives the intended reach. Authorization assignment rules can set these pairs automatically from directory attributes, which is covered in a sibling topic.
Recursive assignment is the setting that most often surprises teams. When a profile is assigned with recursive access, the user receives it in the chosen entity and in its child entities, so an assignment at a parent level can extend into branches that were meant to stay separate. Confirm for each delegated administrator whether recursion is on, and test it with a dedicated account in each child entity before handing over access. Keep the number of top-level assignments small, because each one widens the blast radius of a mistake. Detailed profile design, including the seven default profiles and the life cycle matrix, is covered in the sibling topic on designing GLPI profiles and permissions.
The Super-Admin profile sits outside any delegation model. It can change configuration, entities and other administrators across the whole instance, so it should be held by a very small number of named accounts, each with a separate day-to-day account for ordinary work. Review who holds it on a fixed schedule, remove it from accounts that no longer need it, and record each change. Verify your own assumptions against the GLPI version you run, because administrative controls change between releases; the GLPI 12.0.0 release notes list step-up authentication for certain administrative actions and a view of active sessions that can be revoked, which affect how privileged access is handled. Ask your implementation partner to show, in a test instance, what a delegated administrator can and cannot see from each entity.
How deep entity trees affect performance
Entities are checked against user rights and used to filter nearly every list, form and report in GLPI, so the shape of the tree shapes the work the database does. The cards below name the drivers that tend to matter as the tree grows deeper or wider, and one check to run for each in your own environment.
Recursive visibility checks
When a profile is assigned recursively, GLPI must resolve every child entity beneath the user's entity to decide what that user can see. A deep tree means more entities to resolve on each request, and that cost is paid on every page load, not only at login. Before rollout, log in as a representative technician and time the ticket list and asset search in your largest branch. Compare that against a flatter structure with the same users.
Wide sibling counts
Many sibling entities under one parent make entity dropdowns, filters and assignment rules longer to load and harder to scan. A wide tree of hundreds of clients under a single MSP root can slow the screens that list entities, even when nesting is shallow. Test the dropdowns and the entity selector with the real number of entities you expect in year one and year three, not only the number you have today.
Rule evaluation across entities
Authorization assignment rules and similar matching logic run against each incoming user, and the more entities a rule set must consider, the more work each login and each synchronization performs. Keep rule counts small and order them deliberately. Run a directory synchronization against a copy of your production data and record how long it takes as the number of entities grows.
Report and search scope
Reports, saved searches and global counters that span the whole tree touch every entity beneath the top node, so they grow costlier as the tree grows. A dashboard that is quick for one client can be slow when run from the MSP root across all clients. Ask which reports need a cross-entity view, limit them to the entities they need, and schedule heavy reports outside working hours.
Database growth per entity
Each entity adds rows to tickets, assets, contracts and history tables, and the database indexes that GLPI uses for entity filtering must keep up with that growth. Monitor query times and table sizes as clients are added, and confirm that your database engine has the indexes and memory to handle the combined data. Ask your database administrator to review slow query logs after the first month of production use.
How to set up entities in a GLPI instance
This sequence turns a multi-site or multi-client requirement into a working entity tree, with users scoped to the right places and tested from the seat of a non-admin account. The result is an instance where each site, division or client sees only its own assets and tickets, and the design can be checked before real data arrives.
Confirm the isolation requirement
Before creating anything, the security owner and the service desk lead agree in writing which data must be separated, such as clients, legal entities or divisions, and which data may be shared, such as a central service catalog or a common knowledge base. They also agree who may see across boundaries, typically only the central administrators. Ask the team to state the test for success in one sentence, for example, that a technician in one client cannot list assets or tickets belonging to another. The step is done when this requirement is signed off and the list of separated and shared data is recorded.
Design the entity tree
Draw the hierarchy as a tree on paper or in a design document, with a root entity for the organization or provider and one child entity per isolated unit. Keep the depth shallow, since deep trees add cost to every permission check and make the hierarchy harder to reason about. Decide which concerns belong in groups or locations instead of entities. Groups model teams that work across boundaries, and locations describe physical places. Record the naming scheme and the expected number of entities, then ask the GLPI partner or vendor to confirm the performance guidance for that size. The step is done when the tree is reviewed and each entity has an owner.
Create the entities in the GLPI console
A super-administrator creates the root entity and then each child in the Administration menu, using the names and tags from the design. Set any entity-level settings that differ between units, such as the default ticket behavior, and leave settings that should be shared at the root. Keep a change record of each entity ID and name, because later rules and profiles refer to them. The check is a screen review against the design document, with every entity present, correctly nested, and no stray test entities left behind.
Assign users with profiles and entities
Give each user a profile and the entity or entities they need, using the least-privilege profiles defined for the instance. Set the assignment to apply to child entities only where the design calls for it, because recursive assignment widens what a user sees. Use one test account per role and per scope, and keep administrators separate from everyday technician accounts. If directory synchronization or authorization rules will assign users automatically, confirm that the rules reproduce these assignments before enabling them. The check is an export or review of the user list showing each account, profile and entity, compared against the design.
Populate assets and tickets per entity
Load or create assets, contracts and tickets while the correct entity is active, so that every record is owned by the unit it belongs to. Where data is imported from spreadsheets or an inventory agent, map the source field that identifies the owner to the entity before the import runs, and test the import on a small sample first. Check that shared items, such as a common service catalog, are placed in the root entity and not duplicated in each child. The step is done when a sample of records from each entity has been reviewed and the owner of each is correct.
Verify visibility with non-admin accounts
For each entity and each profile, sign in with a non-admin test account and check what it can see and change. Confirm that assets, tickets, reports and dropdowns from other entities do not appear in lists, search results or direct links, and that the account can perform only the actions its profile grants. Repeat the test for a user assigned to a parent entity with recursive access, to confirm the expected children are visible and no sibling is. Record each result in a test log. The step is done when every scope has a passing test record, and any failure has been fixed and retested.
Security and operational considerations for shared instances
Running several clients or divisions on one GLPI instance concentrates risk in a single application, database and backup set. The cards below cover the controls to design before go-live and the points to confirm with your team or partner, so that entity boundaries hold under administrator, notification and recovery scenarios.
Scope mistakes on assignment
A ticket, asset or user created under the wrong entity can expose one client's data to another, and it is easy to do when technicians switch context quickly. Design entity assignment rules so that new records inherit an entity from the requester, asset location or agent source rather than from a default. Test with two illustrative client entities and a technician who holds rights in only one of them. Confirm which objects can be moved between entities and who may do it.
Administrator reach across entities
Profiles that are recursive apply to child entities, so a broad administrator role in a parent entity can read and change every client below it. Limit super-administrator accounts to a small named group and keep client administrators in profiles scoped to their own entity tree. Review which profiles are recursive and where the Super-Admin profile is assigned. Confirm this review with each client contract, not only with the platform team.
Audit trail separation
Clients often ask who changed their assets or closed their tickets, and the answer must not include another client's activity. Decide whether logs stay in one shared history filtered by entity or whether each client receives a separate export. Make sure administrator actions taken at the parent level are recorded with the entity they touched. Confirm with your auditors or client compliance leads what evidence they will accept and how long it must be kept.
Notifications crossing scopes
Email notifications, followups and satisfaction surveys are sent based on recipients and rules, and a misconfigured rule or a shared group can send one client's ticket content to another client's mailbox. Define notification targets per entity, restrict shared distribution lists, and check templates for fields that show other entities' data. Test notifications with a copy to a test mailbox before enabling them for each client. Confirm who owns the mail relay and whether bounces are routed to the correct entity.
Shared restores and blast radius
A single database and file backup means that restoring one client's data restores every client's data to the same point in time. Plan whether partial restore is supported in your procedure, or whether a restore is an instance-wide decision that needs agreement from all clients. Keep the encryption keys and configuration files with the backup set, and rehearse the restore on a separate host. Confirm the recovery point and recovery time each client was promised.
Upgrades that affect every client
A GLPI upgrade changes the application for all entities at once, and plugins may need reactivation after a new version is detected. Schedule upgrades in a staging copy with representative entity data, and agree a maintenance window that suits the most sensitive client. Keep a rollback plan that includes the database and configuration. Confirm with each client whether they need advance notice of a change to the interface or their workflows.
Questions about GLPI entities and multi-site setups
How much does it cost to design a GLPI entity model?
The cost depends on how many sites, clients or divisions need separate entities, how deep the tree goes, and how many profiles and assignment rules must follow the structure. Design work is usually a one-time cost, while changes to the tree, new clients and rule updates recur. No supplied figure sets this price, so ask any partner for a quote built from a written scope that lists the entity levels, the number of profiles, the directory sources and the test cases. Compare quotes on those items, not on a headline day rate.
How long does it take to set up entities for a multi-site GLPI instance?
Duration follows the number of entities, the directory structure behind them and how much profile policy must be agreed. Most of the time goes to decisions: which divisions or clients get their own entity, who administers each one, and which data must stay invisible across boundaries. Ask for a timeline tied to those decision workshops and to a test phase with real user accounts. No duration is given here because none was supplied for this scope.
What does my team need to provide for an entity design project?
Plan to supply four inputs before the design starts:
- Access to the directory the users come from, such as Active Directory or LDAP, with read rights for group and attribute lookups
- A list of sites, divisions or client organizations, with their legal or billing boundaries
- Your profile policy, including who may see, edit or delete assets and tickets in each area
- A named owner who approves the entity tree and the rule changes that follow
Can our own IT team design and maintain GLPI entities without a partner?
Yes, if your team understands GLPI profiles, entities and assignment rules and can test changes before they reach production. The work is manageable for a small number of entities with a stable structure. It becomes harder when many clients share one instance, when deep trees affect performance, or when auditors need documented evidence of separation. Ask a partner to review your design only if you lack that in-house depth, and keep the decision on who maintains the rules in writing.
When should we split into separate GLPI instances instead of using entities?
Split instances when the separation must be stronger than an entity boundary can give you, such as different legal owners, different upgrade schedules, incompatible plugin needs or a requirement to keep databases apart. Entities suit divisions or clients that can share one platform and one administration model. Decide this before the build, because moving data between instances later is a migration project of its own. Confirm the requirement with your legal and security owners first.
How do GLPI entities interact with LDAP or SSO authorization rules?
Authorization rules assign a user a profile and an entity when they sign in, based on directory attributes or SSO claims. A wrong rule can place a user in the wrong entity or give them a profile with more rights than intended, so the rules must match the entity tree exactly. Test each rule with sample accounts from every group, including leavers and department changes. The same tests should run again after each directory or GLPI change.
Does a deep entity tree slow down GLPI?
Deep trees can add query work because GLPI checks entity hierarchy when it lists and filters records, and the cost grows with the number of entities and the amount of data in each. Keep the tree only as deep as the business needs, and measure page times with realistic data volumes before rollout. Ask any partner to show how they tested performance on a copy of your data, and to state which database sizing they assume.
How DeployOpen works on this
DeployOpen plans, implements, customizes, hardens, documents and supports self-hosted GLPI inside your own infrastructure. For entity designs, we start from how your divisions, clients and sites need to see and administer assets and tickets, then build and hand over an entity tree your team can run.
How we scope
- Written scope lists the entity tree, the divisions or client organizations it models, and the sites and locations inside each.
- Delegated administrators, their profiles and the entities each one manages are named before any configuration starts.
- Scope states which assignment rules, LDAP or SSO attributes and inventory sources feed users and assets into each entity.
How we build
- Entities, sub-entities, profiles and recursive assignment settings are configured in a test instance before production changes.
- Entity depth is kept to what the reporting and access model needs, with the performance effect of deep trees reviewed during build.
- Test cases check that each delegated administrator sees only the entities and tickets within their scope, and that inventory lands in the right entity.
How we hand over
- Documentation covers the entity tree, the reason each entity exists, and the rules that place users and assets in it.
- Runbooks describe how to add a client or site, delegate an administrator and retire an entity without orphaning records.
- Handover includes a walkthrough with the administrators who will maintain the design after the engagement ends.
How we support
- Fixed-scope engagements have agreed deliverables and timelines set in writing before work begins.
- Ongoing support, upgrades and continuous testing are available as a retainer, including checks after GLPI version changes.
- Ask any provider to confirm how entity changes are reviewed and who approves access changes after handover.
