Give several team members the same role and access with groups
A group gives every team member in it a role, which decides what they may do, and permissions on top of their own, which decide where. Use one when several people should do the same things on the same senders, phases, or prompts: change the group once instead of each person's access page. A team member can be in up to 10 groups, and a workspace can have up to 50.
Finding your groups
Go to Settings → Team. The groups are listed under the team members, each with its number of members and the roles it gives. A group that denies or withholds anything carries a Denies badge. Click a group to open its page, or New group to create one.
Admins and Members
Every workspace has two groups to start from:
- Admins gives the Admin role and every permission on the whole workspace, including senders and prompts added later. Its page shows that definition but can't change it, and it can't be deleted: only its members change. The owner is never offered as a member, since the owner already has full access. To make an exception for one admin, add them to a second group that denies it.
- Members gives the Member role and nothing else. It is an ordinary group: give it senders and permissions, rename it, or delete it. New invitations tick it for you.
Roles and scope denies
The Roles card lists the roles a group can give: the built-in Member (read and reply to customers, run reports, edit the prompts their access names) and Admin (everything a member does, plus configuration, the team, integrations, and the Consultant), then your workspace's own roles with their descriptions (see team-roles). Tick one to give it to everyone in the group. A team member holds every role of every group they are in.
The Scope denies card lists what a role can give, grouped by area (workspace and team, configuration, secrets, customers and conversations, analytics, developer, Consultant), by its technical name. A ticked scope is withheld from everyone in the group, whichever group's role gives it to them. For example, a "No secrets" group withholding secrets.write keeps its admins from changing API keys. The owner is never limited by a group.
Roles and scope denies save with the rest of the page. When a group gives the Admin role while withholding some of its scopes, the Roles card notes that every scope later added to Admin reaches the group, and names the scopes a custom role would hold to give the same today (see team-roles).
Setting a group's access
A group's page works like a team member's access page (see team-member-access): its name and description at the top, then the Senders, Phases and Prompts cards, where each cell cycles between not set, ✓ Allow and ⊘ Deny. A group has no specific conversations.
The Whole workspace row at the top of the Senders card applies to every sender, including senders connected later. On the Prompts card, Every prompt does the same for every prompt. While Whole workspace allows any of the five customer permissions, every sender is in the group's scope and the sender switches stay on; deny a sender's permissions on its row to take it away.
A Deny in a group applies to everyone in it and wins over any allow, whether it comes from another group or from the team member's own page. That makes a group the way to take something away from several people at once, for example a "No VIP sender" group denying every permission on one sender.
As you edit, the cells and the summary show what the group gives. Notes under a row point out when a change affects a member. The bar at the bottom of the page counts your changes and offers Save and Discard.
If someone else saves the same group while you are editing it, your save is refused and you are offered to reload the group; reloading discards your unsaved changes.
Who the group alerts
The Notified for card on a group's page sets which escalations alert every member of the group: the whole workspace, a sender, a playbook, or a phase, each at Primary or Backup. It saves with the rest of the page and needs the routing permission. Each member's page shows these rows with the group's name. Notes under the card point out when a change, a save, or adding or removing a member would leave a member notified for conversations they can't read, or let escalations on a sender or phase fall through to the admins or the owner. See escalation-coverage.
Members
The Members card lists the group's team members, and anyone invited into it. Pick a team member and click Add to add them, or click Remove next to a member. These changes apply at once, without the save bar. Save a new group before adding members.
When a group's save or a membership change gives a team member different access, any page they have open reloads to show it, including the page telling them they don't have access to anything yet; if they are in the middle of typing, it waits until they finish.
You can also switch a team member's groups from the Groups card on their own access page, or pick groups when you invite someone in Settings → Team → Add User.
On a team member's access page, what their groups give them shows as ✓ Group or ⊘ Group cells, with the group's name linked under the row.
Who can change a group
You can only give access you hold yourself. Allowing something in a group, giving it a role, removing one of its denies or scope denies, adding someone to a group that allows something, or taking someone out of a group that denies something is refused when you don't hold that access yourself, and the message names what you lack (for a role, each scope you lack, such as "the scope secrets.write"). Adding a Deny or a scope deny is always possible.
Giving more than the Member role gives also needs teams.roles.assign, which the owner holds and can give through a role (see team-roles): giving a group a role beyond Member, removing a scope deny, or adding someone to a group whose roles go beyond Member, such as Admins. Without it, the Roles, Scope denies and Members cards say so, and a save is refused with the names of the owner and the team members who hold it, to ask.
Giving a group a role, removing one of its scope denies, adding someone to a group with a role, or taking someone out of a group with scope denies also asks you to confirm: Yapper asks you to type the group's name, and to sign in again first if your last sign-in was more than 15 minutes ago (see team-roles-and-access).
For the owner, a group gives only which escalations they are notified for: the owner always has full access.
Deleting a group
Click Delete group on the group's page. A group that still has members, or a pending invitation naming it, can't be deleted: remove every member first.
Groups and the Consultant
The Consultant can read your groups (each group's access, members, and pending invitations), the groups each team member belongs to, and your roles. It can propose creating a group, changing a group's name, description, roles, scope denies, senders or permissions, deleting an empty group, and adding team members to a group or taking them out. It can't change Admins itself, only who is in it, and never proposes adding the owner to it. Nothing changes until someone who can approve proposals approves it. The approval card shows each change, and for a group's permissions what the group gives its members before and after. When a group would give the Admin role while withholding some of its scopes, the card notes that every scope later added to Admin reaches the group, and the Consultant proposes a custom role with exactly the scopes it keeps instead (see team-roles). Like the group's page, it also notes when the change would leave a member notified for conversations they can't read, or let escalations on a sender or phase fall through to the admins or the owner. The Consultant can propose a group's Notified for rows too (see escalation-coverage).
A proposal that gives anyone more they can do (giving an existing group a role, removing a scope deny, adding someone to a group with a role, or taking someone out of a group with a scope deny) asks for the same confirmation as on the group's page: you type the group's name, and sign in again if you haven't in the last 15 minutes. Approve it in the dashboard. The rule above applies to whoever approves: a proposal giving access or a scope the approver doesn't hold, or giving more than Member without teams.roles.assign, is refused, with a message naming what they lack and whom to ask. A proposal that would take the Consultant away from a team member while they are using it is marked stale instead of applied; propose it again once their session ends. The Consultant never proposes a Deny or a scope deny that would reach a member of Admins: adding one to a group with one of them in it, or adding one of them to a group with one, is set on the group's page instead. If someone edits the same group, or the same team members' groups, before the proposal is applied, it is marked stale instead of overwriting that edit.