Your groups

This is still the first of the five decisions, Structure & Identity. You’ve set the organization boundary. Now you can move on to what goes into it: your groups and the roles they carry. Groups are the unit that nearly every later decision attaches to.

Groups are the unit nearly every control attaches to

Everything else in this module follows from what a group is and what it carries.

1. A group is a named set of members.

   Your identity provider already sorts your members into groups, and Claude reads them automatically from the SCIM sync. You may have anywhere from hundreds to tens of thousands of members, so configuring one member at a time doesn’t scale. Groups let you configure capabilities for many members at once instead of one at a time.

2. One group structure spans every surface your contract covers.

   You build a single group structure, not one per surface (e.g., Cowork or Claude Code). The role you attach to a group applies across each of Claude’s surfaces, so what that role grants in one product doesn’t have to be remade for the next.

3. Almost every setting in the four decisions ahead attaches to a group:

   Nearly everything you configure, you configure for a group; a handful of settings are organization-wide ceilings instead, and the lessons flag those where they come up.

If you later find yourself wanting to scope a control to a specific subset (“just these three members,” “everyone except contractors”), that’s likely the structure telling you your organization needs another group.

How RBAC works: members, groups, roles

Claude Enterprise uses role-based access control (RBAC). There are three parts to this:

• Members: your people.
• Groups: named sets of members, synced from your identity provider (IdP) over SCIM or, if you don’t sync, created by hand in Organization settings.
• Roles: sets of permissions you attach to a group. Every member on a custom role gets what the roles on their groups grant.

You set access by role, not member by member. To see what a member can do, review the roles on their groups. Change a role, and every member of that group changes at once.

There are three kinds of roles:

• Admin roles (Primary Owner, Owner, Admin): who can change settings, such as inviting members, editing caps, and viewing billing (the last two are Owner-and-above). An Admin can manage members but not billing; an Owner can take every admin action except granting or removing the Primary Owner role; the Primary Owner can take all of these actions.
• User roles (User): what members can do in Claude, including capabilities, model access, and which tools Claude may use on their behalf. Most of this course scopes these through custom roles (see below).
• Custom roles: a permission set you define when the built-in roles don’t fit. It can carry admin or user permissions.

A custom role sets four kinds of access, each of which it can hold differently from the organization-wide default:

• Capabilities: which features are on, for example Claude Code and Cowork.
• Model access: which Claude models the group can use.
• Connector permissions: which connectors the group reaches, and whether it can write through them.
• Admin permissions: for a custom admin role, which admin actions it may perform.

These take effect only for members on a custom role; members on a built-in role keep every surface, model, and connector enabled organization-wide. Setting the role to Custom, by hand or through your IdP role mapping, is part of this lesson’s hand-off.

When a member belongs to more than one group, their permissions are the union of every group’s role. If any group grants a capability, the member has it, and a narrower group cannot remove what a broader one grants. To hold a tighter boundary, put those members in their own group with its own role, and keep them out of the broad group that carries the sensitive permission.

Pluto’s groups

Pluto’s group structure is the hybrid pattern: it mirrors its organization chart, one group per business unit plus a cross-unit Engineering group, everywhere except Payments & Trust, whose engineers would otherwise inherit Engineering’s broad connector access through the union. So Pluto added a dedicated payments-eng group with its own role, and its payments engineers sit there rather than in the broad Engineering group, ensuring they only obtain the permissions they need.

The interactive widget below puts one member in two of Pluto’s groups and shows what she actually gets under the union rule.

1 · Your decision

Which group pattern do your controls attach to: what are your groups, and which of the later controls (surfaces, connectors, governance, caps) does each carry?

2 · The choices you can make

3 · If you change this later

The group structure itself is low stakes to change. You can add a group, rename one, or change the role attached to it. The mapping is what to treat with care: the rule that membership in an IdP group grants a role in Claude. Once a mapping is live, changing it changes access for every member it covers, and reversing it means a second mass change, not a simple undo.

Set up resources

When you’ve made the call, groups and their role assignments live in Organization settings, while membership itself syncs from your identity provider.

• Manage groups and group spend limits on Enterprise plans: creating groups and attaching roles.
• Manage custom roles on Enterprise plans: defining a role when the built-in ones don’t fit.
• Roles and permissions: what each built-in role grants, so a group holds the role that matches the reach you intend.
• Set up role-based permissions on Enterprise plans: attaching a role’s permissions to a group.
• How SCIM sync works for Enterprise organizations: how synced directory groups keep membership current with no manual upkeep.

Lesson activity

Sketch your groups against the union rule: list each group and what its role grants, then name the members or functions that must be tightly bounded and the dedicated group that bounds them. If you have a regulated function, confirm its members are correctly restricted.

What to bring your identity team: the pattern you chose, the rule that turns your IdP groups into Claude groups (plus any exception), any group whose role differs from your standard custom role, and which IdP group maps to the Custom role. If provisioning isn’t yours to run, this is the brief you hand them.

→ Record this in the work-along companion, section Lesson 5.

What’s next

The next lesson covers which Claude surfaces you’ll grant to each group, along with how to phase that access and how the model defaults, organization-wide and per role, decide what each group runs on.