> Source: https://builder.ema.ai/v2/groups/sharing-and-access > Title: Sharing and Access # Sharing and Access Access to a group comes from two places: people added to it directly, and teams nested inside it. The Permissions tab of the group page shows both, and everything the group holds is reached through them. > [TIP] > **Ask Autopilot instead.** Everything on this page can be done by asking Autopilot in plain language. It creates teams and groups, adds and removes people, changes roles, nests teams, and archives and restores, all without opening a form. See [Doing All of This with Autopilot](with-autopilot.md). ## The Permissions tab ![The Permissions tab, with invited user groups above members with explicit access](/builder/v2/assets/img/03-groups/group-permissions-tab.png) The Permissions tab, with invited user groups above members with explicit access Two sections, in the order that matters: - **Invited user groups**, the teams nested into this group, each with the access their people inherit. - **Members with explicit access**, the people added to this group by name, each with their role. Everybody with access to the group can read this tab. Only group admins and Workspace admins see the controls that change it. > [INFO] > **The tables are not the whole list.** Workspace admins manage the group without appearing in either table, and a person reaching the group through a nested team is not in the members table either. Use the **People** count for the real number: unique people, including everyone in nested teams. ## Inviting people **Invite users** searches the people already in your Workspace by name or email. Select everybody you want, pick a role, and confirm. A group gathers people who already exist. To bring somebody new into the Workspace, invite them there first, then add them here. See [User management](/builder/v2/administration/user-management). Roles are described in [Teams](/builder/v2/groups/teams#roles-inside-a-team). ![The role dropdown on a member row, offering Admin, Builder, and Member](/builder/v2/assets/img/03-groups/group-role-dropdown.png) The role dropdown on a member row, offering Admin, Builder, and Member ## Inviting teams ![The Invite user group dialog, listing the teams that can be nested](/builder/v2/assets/img/03-groups/group-invite-teams-modal.png) The Invite user group dialog, listing the teams that can be nested **Invite user group** nests an existing team inside the group. Everybody in that team gets access, including people the team inherits from teams nested inside it. The nesting link carries its own access level, shown in the **Access** column. A team invited with `builder` access gives every one of its people builder rights in this group, whatever role they hold in their own team. Change the level from the same dropdown, and removing the link removes only the inherited access. Nesting is the mechanism to use when the same set of people needs access to several groups. Maintain the team once, and every group it is nested into follows. ## Effective membership **Effective membership** is the answer to "can this person reach this group, and with what role?" once every path has been followed. It is calculated by walking the whole nesting tree, taking every path a person has into the group, and keeping the strongest role found. The order is `admin`, then `builder`, then `member`. So somebody who is a plain member directly and a builder through a nested team is a builder here. People are counted once no matter how many paths reach them, so the People count and the members table rarely match. Everything about a group is decided on effective membership, not on the direct list: opening the group page, using its AI Employees and knowledge bases, reading and writing its tickets. ### All Employees The built-in **All Employees** team means everyone in the Workspace, resolved when it is read rather than stored as a list. Nest it into a group to give the whole Workspace access, and it stays correct as people join and leave. See [Teams](/builder/v2/groups/teams#all-employees). ## Group access and direct shares together A resource can be reached through a group and directly at the same time. The two are added together, and neither interferes with the other. - Removing somebody from a group does not remove a direct share they hold on a resource. - Removing a direct share does not remove what somebody gets through the group. - Where the two disagree about how much access somebody has, the stronger one applies. This matters when you are taking access away. Removing a person from a group is not enough on its own if they were also invited to a resource by name. Check both. ## Reference: endpoints Action Endpoint Read a group with its members, nested teams, and parents `GET /groups/{id}` List everybody with access, deduped and paginated `GET /groups/{id}/effective-members` Add a person `POST /groups/{id}/members` Change a person's role `PATCH /groups/{id}/members/{userID}` Remove a person `DELETE /groups/{id}/members/{userID}` Nest a team `POST /groups/{id}/children` Change a nesting link's access `PATCH /groups/{id}/children/{childID}` Un-nest a team `DELETE /groups/{id}/children/{childID}` ## What's next - [Group-Owned AI Employees and Knowledge Bases](/builder/v2/groups/group-owned-resources) for how ownership interacts with shares. - [Teams](/builder/v2/groups/teams) for roles, nesting, and archiving. - [Governance and permissions](/builder/v2/administration/governance-and-permissions) for Workspace roles and capabilities.