> ## Documentation Index > Fetch the complete documentation index at: https://docs.gradial.com/llms.txt > Use this file to discover all available pages before exploring further. # User Groups > Organize members into role-based and custom groups that can be @-mentioned, assigned as approvers, and assigned to workspaces to grant access — manage teams as a unit, not person by person. User Groups let you address a team as a single unit. Mention an entire squad on a ticket, assign a whole team as an approver, or give the same people access to several workspaces at once — instead of handling five people one at a time and hoping you didn't miss anyone. *** ## Group Types ### Default role groups Gradial automatically maintains a group for each role at both the organization and workspace level: | Scope | Default groups | | - | - | | **Organization** | Owners, Admins, Brand Managers, Designers, Members, Viewers | | **Workspace** | Owners, Admins, Members, Viewers | Membership in these groups is computed from role assignments and workspace access, and stays in sync automatically — when someone's role changes, their default group membership follows. Default role groups are read-only: use them to see or select the people in a role, not to grant a role. Their membership can't be edited directly. ### Custom groups Org owners and admins can build reusable groups of organization members that mirror how your team actually works — squads, regional teams, agency partners, launch teams. Custom groups are the best choice when **the same people need access to several workspaces**. Assign a group to one or more standard workspaces, or leave it unassigned until you need it. *** ## Granting Workspace Access with Groups Assigning a custom group to a workspace gives its eligible members **Workspace Member** access. A group assignment does not grant Workspace Admin, Owner, or Viewer access, and it does not change anyone's organization role. Group-based access is *effective* Member access — it doesn't create a direct workspace-membership record for each person. Access takes effect **immediately** when a group is assigned, so review the group's membership before assigning it. ### When a group changes | Change | Effect | | - | - | | **Adding a person to a group** | Grants the group's workspace access immediately, for as long as they remain an organization member | | **Removing a person, or detaching a group from a workspace** | Removes only that group-based path. Direct access, public workspace visibility, or Organization Owner/Admin access can still apply | | **Deleting a custom group** | Removes the group and its workspace assignments. Does **not** remove anyone from the organization | | **Removing someone from the organization** | Removes them from custom groups and from group-granted workspace access. Re-adding them to the organization does not restore their former group memberships | Removing someone's direct workspace membership is not a permanent block. If they're still in a custom group assigned to that workspace — or are added to one later — they keep or regain Member access. See [How Access Paths Combine](/docs/integrations-administration-and-setup/managing-access/roles#how-access-paths-combine). *** ## Managing Groups Groups are managed from **Organization Settings → People → Groups**. The Groups tab provides: * Tabs and filters by scope, type, and member * Inline member editing for custom groups * Create and edit dialogs for building new groups **To create a custom group:** 1. Go to **Organization Settings → People → Groups** 2. Click to create a new group 3. Give the group a name and, optionally, a description 4. Add at least one current organization member 5. Optionally assign the group to one or more workspaces 6. Save Group lifecycle and membership changes are audit-logged. *** ## Group Mentions Groups appear in the **@** mention picker anywhere mentions work. Mentioning a group notifies every member of the group who has access to the ticket, in one action — the author is excluded from their own mention's notifications. > *"@Web Squad — can you review the updated hero copy on the summer campaign pages before Friday?"* Because default role groups stay in sync with roles, mentions like **@Admins** or **@Designers** always reach the current set of people in that role — the mention never goes stale as the team changes. See [Mentions](/docs/platform/mentions) for how the mention picker works. *** ## Group Approvers Workspace-scoped groups can be assigned as a ticket's **approver**. Any member of the group can complete the approval, so reviews never wait on one person's availability. Group approvers are supported everywhere individual approvers are: ticket creation, editing, bulk operations, filters, and Excel upload. Removing a legacy workspace-scoped group from its workspace can set affected Task approvers to **No approver**. Restoring the group's scope does not restore those approver assignments automatically, so reassign approvers after the change. *** ## Permissions | Action | Who can do it | | - | - | | View groups | All organization members | | Create, edit, and delete custom groups | Org owners and admins | | Edit group membership | Org owners and admins (custom groups only) | | Assign a custom group to a workspace | Org owners and admins | Only people who can manage organization settings — normally Organization Owners and Admins — can create, edit, delete, or assign custom groups. *** ## Limitations * **Default role groups are read-only** — membership is synced from roles and can't be edited directly. * **Group assignments grant Member access only** — use a direct workspace role for Admin or Viewer access. * **Same-organization only** — a custom group can contain only members of its own organization, and can be assigned only to active standard workspaces in that organization. Admin workspaces can't have group assignments. * **Only workspace-scoped groups can be approvers** — org-scoped groups can be mentioned but not assigned as ticket approvers. *** ## Related * [Roles & Permissions →](/docs/integrations-administration-and-setup/managing-access/roles) — the role model that powers default groups * [Adding Team Members →](/docs/integrations-administration-and-setup/managing-access/manage-team-members) — inviting users and configuring access * [Mentions →](/docs/platform/mentions) — the @ picker where groups appear *** ## Availability **Access:** Must be enabled for your organization. Contact your Gradial team to get access. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.