> For the complete documentation index, see [llms.txt](https://docs.spectralink.net/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.spectralink.net/amie-advanced/planning-and-installation/planning-your-groups.md). # Planning your groups AMIE Advanced gives your organization one [Space](/amie-advanced/introduction/how-your-space-is-organized.md) and, inside it, a tree of groups and subgroups that you shape yourself. Every device and every user belongs to exactly one group. The tree decides two things: how the figures on most screens are divided up, and which part of the fleet each user can see. Deciding the tree is the planning decision that shapes everything else, and this page is about making it. ## Groups are logical, not physical A group does not have to be a place. The previous console tied devices to Locations; in AMIE Advanced a group can be a department, a functional team, a shift, or a region — whatever you want to monitor as a unit. Handsets used across several facilities or buildings can sit in one group, so that a team such as the emergency department or IT is monitored as a team wherever its people are working. Subgroups let you divide further. A hospital might create groups directly beneath the top of the tree for **IT**, **Clinical** and **Facilities**, and beneath **Clinical** subgroups for functional departments such as the emergency department (**ED**) or neonatal intensive care (**NICU**). Selecting **Clinical** in the [group selector](/amie-advanced/using-the-platform/the-console.md#the-group-selector) then shows every clinical handset; selecting **NICU** shows only that unit's handsets. Regional or location-based names — **East Region**, **West Region**, a building name — work just as well if that is how you run your fleet. The tree is not tied to geography; it is tied to how you want to see the numbers. ```mermaid flowchart TD S["Your Space (top of the tree)"] IT["IT"] CL["Clinical"] FA["Facilities"] ED["ED"] NICU["NICU"] S --> IT S --> CL S --> FA CL --> ED CL --> NICU ``` ## Users see what their group contains Each user is placed in one group and can see that group and everything beneath it, on every screen, and nothing else. A user placed at the top of the tree sees the whole fleet. A user placed in **Clinical** sees **Clinical**, **ED** and **NICU** and has no way to reach **IT** or **Facilities**. Place the people who need fleet-wide visibility at the top, and everyone else in the group they are responsible for. What a user can do within what they see is decided separately by their role — see [Roles and permissions](/amie-advanced/using-the-platform/roles-and-permissions.md). ## What the tree gives you * Figures divided the way you work. Select a group in the console header and the Dashboard, Devices, Performance and Access Points screens show that group and its subgroups only — see [Which screens follow the selector](/amie-advanced/using-the-platform/the-console.md#which-screens-follow-the-selector). * Devices that follow the team. A handset belongs to a group, not to a building, so a team's devices stay together as the team moves between facilities. * Users who see only what they are responsible for, and administrators who see everything. {% hint style="info" %} Not yet available: moving a device to another group. **Move to Group** on the Devices inventory is grayed out and marked **Coming soon**. \[GAP-devices-3] {% endhint %} ## Recommendations * Start with the groups you will want to compare. If you will ask "how are the ED phones doing against the rest of the hospital?", **ED** must be a group. * Keep the top of the tree for the whole fleet. Put department and team groups beneath it, so that one selection shows everything. * Place administrators at the top and everyone else as low as their responsibility allows. A user's group cannot be changed in this console afterwards; see [Change someone's role or group](/amie-advanced/using-the-platform/roles-and-permissions.md#change-someones-role-or-group). * Record physical places as sites, not groups. Sites give access points a location — see [How your Space is organized](/amie-advanced/introduction/how-your-space-is-organized.md). ## Create a group The [Groups](/amie-advanced/using-the-platform/settings/settings-groups.md) tab describes the screen in full. Requires the **Admin** or **Owner** role. {% stepper %} {% step %} Select **Settings** in the sidebar, then the **Groups** tab. The tree of groups you can see is listed. {% endstep %} {% step %} Select **Add Group**. The **Add New Group** dialog opens with the top of the tree chosen under **Parent Group**. To add a group beneath a particular group instead, point at that group in the tree and select the **+** that appears beside it; the dialog opens with that group chosen as the parent. {% endstep %} {% step %} Enter a **Group Name**, change **Parent Group** if you need to, and select **Add Group**. The new group appears in the tree beneath its parent. {% endstep %} {% endstepper %} A trash icon also appears when you point at any group except the top of the tree. It does nothing yet. \[GAP-groups-1] --- # 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 by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.spectralink.net/amie-advanced/planning-and-installation/planning-your-groups.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. 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.