> For the complete documentation index, see [llms.txt](https://help.glpi-project.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.glpi-project.org/documentation/12-en/welcome-to-glpi-12/the-fundamental-concepts.md). # The fundamental concepts GLPI is built on two pillars that must be considered from the very beginning of instance setup: * **Entities** * **Profiles** Once these pillars are understood, it will be possible to populate the instance by creating or importing users and groups. *** ## Entities The "concept" of entities is essential for structuring an instance. It allows for the segregation of different parts (departments, clients, suppliers, etc.), ensuring isolation between them and enabling simpler, personalized management. * **Hierarchy**: Entities are organized in a tree structure (Parent/Child). * **Inheritance**: What is defined in a parent entity can be made visible in child entities (e.g., a global maintenance contract). *Example of entity architecture*: ```yaml 🛑 Root Entity (The Group / The Holding Company) │ (Manages global items: global licenses, cross-functional users, etc.) │ ├── 🏢 Parent Entity: Headquarters (Paris) │ │ (Manages the inventory and tickets for the headquarters) │ │ │ ├── 👥 Department: Human Resources │ │ └── 📄 Sub-department: Payroll & Administration │ │ │ ├── 💰 Department: Finance │ │ └── 📊 Sub-department: Management Control │ │ │ └── 💻 Department: IT (CIO) │ │ │ ├── 🛠️ Department: Technical Support (Helpdesk) │ │ └── 📞 Team: Level 1 │ │ │ └── 🏗️ Department: Infrastructure & Networks │ └── 🌐 Team: Network & Security │ └── 🏭 Child Entity: Production Site (Lyon) │ (Autonomous for its local inventory and tickets) │ ├── 🔧 Department: Industrial Maintenance └── 📦 Department: Logistics ``` {% stepper %} {% step %} **The root entity**: often accessible to administrators for GLPI management. If access to sub-entities has been explicitly granted, the administrator will have access to all entities and sub-entities. {% endstep %} {% step %} **Segregation (Isolation)**: An administrator of the `IT (CIO)` entity sees everything within their entity, as well as within `Technical Support`, `Infrastructure`, etc. However, they do not see what is within `Human Resources`. A ticket created in the Production Site (Lyon) entity is completely invisible to users at the Headquarters (Paris), unless a global administrator has access to it. This addresses confidentiality issues or multi-company management. {% endstep %} {% step %} **Assignment**: Each piece of equipment (PC, Server, etc.) and each ticket must be assigned to one specific entity within this hierarchy {% endstep %} {% endstepper %} See more about entities *** ## Profiles Profiles allow permissions to be assigned to users. Within an entity, they can have specific permissions (view inventory, modify tickets, add articles to the knowledge base, etc.). It is possible for a user to have different profiles across different entities. A profile defines what a user is allowed to do. 2 interfaces are available for profiles: * **Simplified**: Minimal interface for end-users to create tickets. * **Standard**: The main interface for instance administration. See interface details {% hint style="success" icon="head-side-brain" %} **Golden Rule**\ A user alone has no permissions. An authorization, meaning a Profile *applied to* a specific Entity, is necessary.\ \ Example: I am a "Technician" for the "Technical Support (Helpdesk)" entity, but "Self-Service" for other entities. {% endhint %} The formula to understand is: > \[User] has \[Profile X] on \[Entity Y] **📋 Concrete Example:** Julie works in technical support in Lyon, but she is also a standard user for the group. | Entity | Profile | Result | | ----------- | ----------------------------------- | -------------------------------------------------------------- | | Root Entity | Self-Service (simplified interface) | Julie can create her own tickets for the group. | | Lyon Site | Technician (standard interface) | Julie can view and resolve tickets for her colleagues in Lyon. | | Paris Site | None | Julie does not see that the Paris entity exists. | See more about profiles *** ### Groups and Users * **Users**: Individuals (can be created in the internal database, synchronized from LDAP/Active Directory, or via other tools like SCIM). * **Groups**: Sets of users. An important concept for collaborative work. For example, assigning a ticket to the "Level 2 Support" group rather than directly to Julie. In case of absence, service interruption is avoided. See more about groups and users --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://help.glpi-project.org/documentation/12-en/welcome-to-glpi-12/the-fundamental-concepts.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.