Skip to main content

Manage access with groups

Use this guide to grant access in bulk. A group is a reusable set of members that you configure once, then use anywhere you would otherwise add people one at a time. You'll create a group, add members, and grant access through it.

  • Deployment: SaaS, On-premises
  • Role: Owner, Admin

When you have more than a handful of members, grant access through groups instead of person by person. A group exists purely to hand out access to everyone in it at once.

Before you begin​

To manage groups, you need all of the following:

  • Owner or Admin on the organization: Managing users and groups requires one of these roles. See Roles reference.
  • A clear reason the group exists: for example a group for your dev leads, so you can grant them a work area in one step.

There is currently no directory or SSO group sync. Groups are managed in CodeTogether AI.

1. Create the group​

  1. Go to Settings > Access > Groups.
  2. Select Create group.
  3. Name the group.
  4. Add its initial members.
  5. Select Create group to finish.

Afterward, Configure lets you rename it, add or remove members, and set the conferred system role.

2. Choose how the group grants access​

A group can grant access two ways, and you can use either or both:

  • A conferred system role, set on the group itself. Open the group's Configure drawer and pick a conferred system role of None, Owner, Admin, Global viewer, or Member — the tenant roles, plus None. Every member of the group inherits it.
  • A work area role, granted from a work area rather than from the group. In a work area's access settings, add the group as a principal with a role of Admin, Viewer, or Self-only. Everyone in the group inherits that work area access.

Use a conferred system role for organization-wide access, and a work area grant for access to one area. See Create a work area for granting a group a work area role.

3. Understand how grants combine​

When a person's access comes from several places, a direct grant plus one or more groups, they receive the most permissive role across all of them. This applies even when the direct grant is Self-only: it narrows a person's own access, but a stronger role from a group grant on the same work area still wins. Adding someone to a group can only raise their access, never lower it.

Deleting a group revokes the roles it conferred from everyone in it. To revoke one person's access, remove them from the group instead.

Troubleshooting​

A member has more access than expected​

Access is the most permissive role across every source. Check the person's direct grants and every group they belong to, because any one of them can be the source.

Removing a member from a work area did not remove their access​

If their access also comes from a group granted on that work area, removing the direct grant leaves the group grant in place. Remove them from the group, or remove the group's grant.

If this doesn't fix it​

Contact support with all of the following. Tickets missing these take longer to resolve:

  • The group name, its conferred system role, and the work areas it is granted on.
  • The member whose access looks wrong, and the access you expected.
  • Your deployment kind and server version.