What an individual can see and do in their Team or Enterprise plan account is dictated by their role. Roles are provisioned with the following permissions.

About custom roles (Enterprise plans only): Enterprise plans support custom roles, which let you control feature access at the group level. Members with roles set to “Custom” have no default permissions—their access is determined entirely by the custom roles assigned to their groups. Because these members have no built-in permissions, they don't appear in the tables below.

To learn more, refer to the following articles:

This guide walks you through setting up role-based permissions for your Enterprise organization. This lets you control which features and connectors specific teams or groups of members can access, and delegate specific admin access like billing or user management, rather than giving everyone the same permissions.

Before you start, make sure you're familiar with:

You'll need Owner or Primary Owner access to your Enterprise organization, or a custom role with Identity & Access set to Manage.

Check which capabilities are enabled at the org level. Go to Organization settings and ensure you know which capabilities members can access currently. For settings managed by RBAC, both the org setting and role setting are required to be on for users to get access.

Back up your member list. Export a CSV of your current members from Organization settings > Members before making any changes. If something goes wrong during migration, this gives you a reference to restore access. See Manage members on Team and Enterprise plans.

Determine which teams or functions need each capability. For example, Engineering gets Claude Code + Fast Mode and Marketing gets Cowork + Web Search. From here, define your custom roles.

Dual-seat plans. If your organization is on a dual-seat Enterprise plan (with Chat and Chat + Claude Code seats), custom roles don't override seat-level restrictions. A member assigned to a Chat-only seat can't access Claude Code even if their custom role grants it. The same applies in reverse: if a member's custom role doesn't grant the chat capability, they won't have chat access regardless of their seat type. Plan your role structure with seat assignments in mind.

Decide how you'll create groups. You can create groups manually in Claude, or sync them from your identity provider (IdP) via SCIM. You can also use both methods simultaneously. If you plan to use IdP groups from Okta, Entra ID, or another provider, make sure SCIM directory sync is configured. See Set up JIT or SCIM provisioning.

Add the connectors you plan to govern. Connector permissions only cover connectors that an Owner or Primary Owner has already added under Organization settings > Connectors and connected with admin credentials. Review your organization-wide tool policy there as well, since role grants narrow within it and can’t widen past it. See Use connectors to extend Claude’s capabilities.

Before creating anything, decide which features each team or group of members should have access to. Here are four common patterns:

This is the recommended approach for most organizations. Create a "Standard Access" role for everyone with common features like web search, memory, and projects. Then create additive roles that grant specific capabilities — for example, a "Cowork Enabled" role that only adds Cowork. Assign all members to the base role through an "All Users" group, and add specific members to additional groups that layer on extra features.

This pattern is flexible because permissions are additive — combining a base role with additive roles composes cleanly without conflicts.

Create distinct tiers: "Full Access" with all features, "Standard Access" with most features, and "Restricted Access" with minimal features. Each member goes into exactly one group assigned to one tier.

Create roles that map to departments: "Engineering" with chat, Cowork, Claude Code, and code execution; "Research" with chat, web search, memory, and projects; "Business" with chat, web search and projects only. Assign each department group to its corresponding role.

Create roles that delegate parts of administration without granting the Owner role. A custom role with admin permissions does not need any user capabilities, and vice versa. You could create a "Finance" role that grants Billing access but no chat or Claude Code capability, or an "Engineering Lead" role that grants Claude Code plus Analytics view access. Learn more about admin permissions for custom roles.

Remember: any feature you want to control per-group must be enabled at the organization level. If a feature is toggled off at the organization level, no custom role can grant access to it.

Create your custom roles before enabling any features or migrating members. This ensures your roles are ready to enforce access the moment features turn on.

Role changes may take up to 15 minutes to take effect. Members may need to refresh their browser to see updated access.

See Manage custom roles on Enterprise plans for details on available capabilities, admin permissions, and connectors.

Set admin permissions on each role to delegate access to admin settings, like billing, user management, or privacy, without granting the Owner role. This step is optional. If you don't configure it, roles grant no admin access and administration stays with Owners and Primary Owners. For what each permission area covers, see Manage custom roles on Enterprise plans.

The Permissions tab lists each admin area: Identity & Access, Billing, Analytics, Privacy, User Management, and Libraries. Set each admin area to one of the following options:

Within an area, you grant all of View or all of Manage. You can't grant or restrict individual pages or settings.

Verify admin permissions after you’ve migrated members to "Custom" roles (Step 7). See Step 11: Verify and monitor.

Set connector permissions on each role to control which connectors, and which tools on those connectors, the role can use. This step is optional. If you don’t configure it, your roles fall back to the default behavior described below. For how the permission model works end to end, see Manage custom roles on Enterprise plans.

The default settings for new roles are permissive. When creating or modifying a role, confirm the settings on each tab to avoid granting unintended permissions.

The Connectors tab lists an All connectors row at the top, followed by every connector your organization has added. Each row has a dropdown with four options:

Choosing “Always allow,” “Needs approval,” or “Blocked” applies that level to every tool on the connector. The All connectors row works the same way one level up: it sets a baseline for every connector at once, including any connector you add later. Use it to set a role’s default, then override individual connectors.

Set a connector to Custom to reveal its tools as individual rows. Each tool has its own dropdown: “Always allow,” “Needs approval,” or “Blocked.”

Per-tool permissions let a role reach part of a connector. For example, with Jira set to Custom, its search_issues tool set to “Needs approval,” and every other Jira tool set to “Blocked,” members with the role can search Jira but nothing else. Claude only sees the tools you’ve granted, so asking it to create a ticket returns “I don’t have a tool for that” rather than an error.

Because connector permissions are additive across roles, blocking a connector in one role has no effect on a member who also holds another role that grants it. Each connector row shows a warning when other roles grant the same connector at a different level. The warning names those roles and links to them, and the most permissive grant is the one that applies.

If you have unsaved edits when you open a linked role, you’re asked to discard them first.

Verify connector permissions after you’ve migrated members to "Custom" roles (Step 7). See Step 11: Verify and monitor.

Set model access on each role to control which Claude models the role can use, cap the maximum effort level per model, and choose the model new conversations start on. This step is optional; if you don't configure it, new roles can use every model that's enabled at the organization level, at any effort level, and start on the organization default model.

For how the model access and default model settings work end to end, see Manage model access for your organization and Set a default model for your organization.

Under Model access, switch each model on or off for this role. Models disabled at the organization level appear but can't be enabled here until you turn them on for the organization in Organization settings > Models. Haiku models are always on and can't be disabled.

To cap the effort level a role can select on a model, click the gear icon next to the model and choose a level.

Under Default model, optionally select the model new conversations start on for this role. Only models the role has access to can be selected.

Verify model access after you've migrated members to "Custom" roles. See Step 11: Verify and monitor.

If you use SCIM directory sync, you can sync groups from your identity provider instead of creating them manually. For details on SCIM group sync, see Manage groups and group spend limits on Enterprise plans.

Multiple organizations under the same parent organization: Groups are managed at the parent organization level and propagate to all child organizations. You may see members from other organizations listed in a group—this doesn't mean they have access to your organization. Custom roles assigned to a group only grant capabilities to members who are part of your specific organization.

If you request to move an organization from one parent to another (this is rare in practice), groups and roles will become undefined and you will need to re-create them.

Before migrating members to custom roles, confirm that every member you plan to migrate is in at least one group assigned to a custom role. Members who are migrated without group or role coverage will lose access to all governed features.

For custom role capabilities to take effect, members must have their role set to "Custom." Members with the User, Admin, or Owner roles get their permissions from those roles directly, not from custom roles.

Choose the migration path based on whether your organization already enabled group mappings:

Use this path only if your organization already enabled group mappings for role assignment. If you aren't already using this setting, skip to Path B.

Members in IdP groups mapped to "Custom" roles follow the permissions of the custom roles assigned to their groups in Claude. Members in IdP groups mapped to User follow the organization-level capability settings. If a member is in groups across both mappings, "Custom" roles take precedence.

Use this path if your organization hasn’t enabled group mappings.

We recommend migrating a pilot group first—one team or department—and verifying their access is correct before expanding to the rest of the organization.

Whichever path you use, we recommend migrating in stages:

Only enable organization-level features after roles, groups, and member migration are complete. This ensures custom role capabilities are already in place, with no window where unauthorized members could access a feature.

For any feature you want to control per-group:

Enabling a feature at the organization level doesn't mean everyone gets it—custom role permissions are already in place to control who can use it. Think of the organization-level toggle as making the feature "available for role-based assignment" rather than "on for everyone."

Navigate to the “Usage” page to assign a per-user monthly spend limit to any group.

Note the following precedence rules:

Membership changes take effect automatically—users inherit or lose limits as soon as their group membership changes. Relevant only for usage-based billing orgs.

If you configured admin permissions, also check:

If you configured connector permissions, also check:

If you configured model access, also check:

Role changes may take up to 15 minutes to take effect across the platform. Members may need to refresh their browser to see updated access.

SCIM connects to your role-based capabilities through two mechanisms that work together.

This controls which built-in role a member gets when they're provisioned. Map your IdP groups to "Custom" roles so that new members' access is automatically governed by custom role capabilities.

This pulls your IdP groups into Claude so they can be assigned to custom roles.

If you notice your role structure is misconfigured after migration:

If you enabled group mappings during setup and lost admin access, follow the recovery steps in Set up JIT or SCIM provisioning under "I lost Admin/Owner access after enabling group mappings."

Yes. The organization-level toggle must be on for custom roles to control per-member access. If a feature is off at the organization level, no one can access it regardless of their role. Think of it as a main switch—custom roles control who gets access underneath it.

They have no custom role permissions, so all features that require permissions are greyed out or hidden. Make sure every member whose roles is set to "Custom" is in at least one group that's assigned to a custom role.

Either the model is disabled at the organization level (Organization settings > Models) or none of the member's custom roles grant it. Org-level disables affect everyone, including Owners and Admins.

Members in that role won't see Claude's chat interface. They'll land on their settings page when they sign in. If their role grants other products like Cowork or Claude Code, those remain accessible from their settings page and from the relevant apps.

Chat is enabled by default in all custom roles, so you only need to worry about this if you intentionally toggled chat off for a role.

Yes. Members with the User, Admin, or Owner roles are unaffected by custom role permissions because they get their permissions from those roles directly. Only members with a role set to "Custom" are controlled by the group-and-role system. This allows gradual migration.

Permissions are additive. If any role in a member's chain grants a feature, they have it. You can't use a role to remove a permission granted by another role.

Yes. Both types can be assigned to custom roles. The difference is that SCIM group membership is managed in your identity provider, while manual group membership is managed in Claude's organization settings.

No. Owners and Primary Owners always have full access to all features.

Groups and SCIM sync are managed at the parent organization level and shared across all child organizations. Role and spend limit assignments are configured independently in each child organization—changes in one child organization don't affect others. Group membership changes and SCIM resyncs propagate across all child organizations under the same parent.

Each existing role is seeded with the “All connectors” grant at “Always allow,” so members’ access doesn’t change at enablement. You narrow access from there.

“Needs approval” on every connector. The create-role flow steps through the Connectors tab so you see this before saving.

A role whose “All connectors” row is set to “Always allow,” “Needs approval,” or “Blocked” covers the new connector at that level automatically. A role whose “All connectors” row is set to “Custom” treats the new connector as “Blocked” until you set it.

Check whether the member holds another role that grants it, since the most permissive grant wins across roles. The conflict warning on the connector row lists those roles. Also confirm the member’s role is set to "Custom."

No. The organization-wide policy is the ceiling. A tool blocked there is blocked for everyone, regardless of role grants.

The role can grant it, but the stricter setting wins, so members see it capped at “Needs approval.” To let members set “Always allow,” raise the organization-wide policy to “Always allow” first.

Yes. Set the connector to “Custom,” set the one tool to “Always allow” or “Needs approval,” and leave the rest “Blocked.”

No. Built-in features are governed on the Capabilities tab. The Connectors tab governs connectors your organization has added.

Role changes may take up to 15 minutes to take effect. Members may need to refresh their browser.

Only if their role includes Identity & Access set to Manage, which covers editing roles and groups. Reserve that permission for trusted security and IT administrators, since it can be used to change role definitions including their own.

No. Admin permissions only apply to members in a custom role. Members on a built-in role keep the access that role grants. To give someone specific admin permissions, change the member to a custom role and add them to a group assigned to a role with the permissions they need. Keep in mind this removes their previous built-in role access.

Organization settings only shows the sections their permissions cover. Sections they don’t have access to are hidden entirely from their organization settings.

Organization settings > Roles shows the admin permissions each custom role grants, and Organization settings > Groups shows which groups are assigned to each role and who belongs to them. To check a specific member, look up their groups on Organization settings > Members, then the roles those groups are assigned to.

Create one role that grants access to multiple areas, or add the member to multiple groups whose roles cover the areas they need. Permissions combine additively.

Custom roles let you define which features your members can access. Each custom role contains a set of permissions that grant or restrict access to specific capabilities like chat, Claude Cowork, Claude Code, and web search, plus the connectors your organization has added, such as Slack or Google Drive. Custom roles can also grant admin permissions, which give members access to specific administrative areas like billing, identity, or privacy without making them Owners.

Custom roles work alongside groups. The typical workflow is: create custom roles, assign them to groups, and then set members' roles to “Custom” so their access is governed entirely by the custom roles assigned to their groups.

Feature access is determined by a four-level precedence chain, where the most restrictive level wins:

The key takeaway: the organization-level toggle is a main switch. Custom roles are the per-member switches underneath it. A feature must be enabled at the organization level before custom roles can control who gets access.

Each custom role can grant or restrict access to the following capabilities:

Custom roles also govern admin permissions, connectors, and model access, which are configured on separate Permissions, Connectors, and Models tabs in the role editor. See Admin permissions, Connector permissions, and Model access below.

Role changes may take up to 15 minutes to take effect, and members may need to refresh their browser. All members in groups assigned to this role are affected.

Click the menu button on any custom role and select “Delete role.” Deleting a role removes its permissions from all groups it was assigned to. Members in those groups lose the permissions the role granted, unless another role in their chain also grants them.

Custom roles are assigned to groups, not directly to individual members. To assign a group to a role:

You can also assign custom roles when creating or editing a group in Organization settings > Groups. See Manage groups and group spend limits on Enterprise plans.

If a member belongs to multiple groups with different custom roles, their permissions are additive—they get the union of all permissions from all roles in their chain. If any role grants a feature, the member has access to it.

This means you can't use one role to remove a permission granted by another role. This is by design — it enables a layered approach where a base role covers common features and additional roles layer on specific capabilities and admin permissions.

Example: A member is in two groups. The "All Users" group is assigned a "Standard Access" role with web search and memory. The "Engineering" group is assigned a "Developer" role with Cowork and Claude Code. The member gets all four: web search, memory, Cowork, and Claude Code.

When a member belongs to several groups whose roles grant different capabilities, it can be hard to tell what they can actually do. The "View effective role" option shows the combined result: every capability, admin permission, and connector the member has, with the role that grants each one.

The modal lists the member's assigned roles and three tabs:

This view is read-only. To change what a member can do, edit the roles assigned to their groups.

Custom roles can grant admin permissions in addition to capabilities and connector permissions. Admin permissions give members access to specific administrative areas, like billing or privacy, without making them Owners. You can configure admin permissions in the Permissions tab of the role editor.

On the Permissions tab, you set each permission area to one of three levels:

Within an area, you grant all of View or all of Manage. You can't grant or restrict individual pages or settings.

There are seven admin permission areas:

The following remain available only to Owners and Primary Owners, even for members with admin permissions:

If a member doesn’t have access to a specific admin permission, the section doesn't appear in their organization settings. Only sections their permissions cover are shown.

Custom roles also control which connectors, and which tools on those connectors, a role can use. Where capabilities cover Claude’s built-in features, connector permissions cover the apps and services you’ve connected to your organization, such as Slack, Google Drive, or Jira. You set them on the Connectors tab of the role editor, next to the Capabilities and Permissions tabs.

On the Connectors tab, you set all connectors, each connector, or each tool on a connector, to one of three levels:

A connector can also be set to Custom, which lets you set each of its tools individually. For the full setup, see Set up role-based permissions on Enterprise plans.

A connector or tool passes through several layers before a member can use it, evaluated in this order:

For members using Claude Code, one more layer applies: Managed Settings policies and connector permissions compose by most-restrictive. A tool is callable without a prompt only when both allow it. For more information, see Claude Code settings.

This table shows how the organization-wide tool policy and a member’s role grant combine:

Connector permissions are enforced on Anthropic’s servers, so they apply across every Claude surface that routes connector traffic through Anthropic:

Connector permissions govern connectors your organization has added under Organization settings > Connectors. They don’t govern connectors a member runs locally on their own machine, and they don’t govern Claude Cowork when it’s deployed on a third-party platform. For third-party Cowork deployments, use MDM instead. See Cowork on 3P: MCP, plugins, skills, and hooks.

Members can’t tell which layer restricted a tool. The message is the same whether the limit comes from the organization-wide tool policy, a role grant, or both. To find the source, compare the organization-wide policy with the member’s role grants.

Custom roles also control which Claude models a role can use and the maximum effort level members can select on each one. You set these on the Models tab of the role editor, alongside the role's default model.

The organization-level model setting is the ceiling. A role can't grant a model that's disabled at the organization level. Across a member's roles, model access is additive and effort limits take the highest cap any role allows. Haiku models are always available and can't be disabled.

For setup steps and what members see, see Manage model access for your organization. For default model behavior, see Set a default model for your organization.

When a capability is restricted, here’s what members see. For connector and tool restrictions, see Connector permissions above.

This guide covers how to configure user provisioning and role assignment for your Claude or Claude Console organization.

Before you begin: This guide assumes you have already completed the steps in Set up single sign-on (SSO), including domain verification and SSO configuration with your Identity Provider (IdP), and you have an Admin (Console) or Owner (Claude) role.

Once SSO is configured, you need to decide how users will be provisioned to your organization. This is controlled via the User provisioning section in Organization settings > Organization and access.

Invite only is the default. Users are added and removed directly in Claude or Console settings.

Just-in-time (JIT): Users assigned to your Anthropic IdP app are automatically provisioned when they first log in. This option is available to all plans.

SCIM directory sync: Users are automatically provisioned and deprovisioned based on assignments in your IdP, without requiring them to log in first. SCIM is available for Enterprise plans and Console organizations with their own parent organization or joined to an Enterprise parent organization. SCIM is not available for Team plans or Console organizations joined to a Team plan's parent organization.

Use this table to help decide which provisioning mode is right for your organization:

Both JIT and SCIM can be combined with Enable group mappings to control role or seat tier assignment based on IdP group membership. If you select either of these options for your provisioning mode, Enable group mappings will appear within the User provisioning section:

For information on purchasing seats or adjusting your plan's seat allocation, see our guides for Team plans and Enterprise plans.

If you chose SCIM as your provisioning mode, you need to establish the connection between your Identity Provider and Anthropic before enabling it.

‼️ When you reach the IdP Group step, pause to review Steps 3 and 4 of this guide, alongside the other guides.

For IdP-specific JIT / SCIM setup instructions, see:

Once your IdP is connected, continue to Step 3.

Verify you have enough seats purchased and available to add members to your org.

This happens when the person configuring group mappings isn't assigned to a group mapped to an Admin or Owner role, causing their permissions to be downgraded to User.

To fix this:

Option 1: Have another Admin/Owner reinstate your role

Option 2: Fix via your Identity Provider

This guide covers the steps to configure SSO for Team and Enterprise plans, and Claude Console organizations.

Before proceeding with SSO setup, complete the following:

Review the considerations guide: Read Important considerations before enabling single sign-on (SSO) and JIT/SCIM provisioning to understand parent organizations, determine your setup path, and complete any prerequisite steps such as merging organizations.

Confirm you have the required role:

Confirm you have access to the following:

Please contact your organization's IT Administrator if you do not have permissions to manage Claude or company DNS settings.

Domain verification proves that you own your company's domain. Once verified, you can configure SSO for accounts with your company's domain.

You can verify multiple domains for a single organization, but all domains must be managed through a single IdP. We don't support verifying domains from separate IdPs within the same organization.

Clicking "Refresh" re-checks your DNS; it won't show Verified until the published TXT record exactly matches the expected value. If it stays Pending after DNS has propagated, check the following:

If the record is correct and propagated but the status still shows Pending, contact Support.

For IdP-specific setup instructions, see:

You can now choose to toggle on Require SSO for Console and/or Require SSO for Claude, on the Organization and access page, under the Authentication section:

When SSO is required, users must use the “Continue with SSO” option to log in to their Claude/Console accounts. When SSO is not required, they will have the option to choose “Continue with SSO” or “Continue with email.”

Before you decide, review What happens to existing users when SSO is enabled.

Once SSO is enabled, you need to decide how users will be added to your organization by choosing an option within the User provisioning section of your Organization and access settings.

Invite only is the default. Users are added and removed directly in your Claude or Console settings. Please see Manage members on Team and Enterprise plans.

Just-in-Time (JIT) provisioning can be enabled to automatically provision users when they first log in. By default, users assigned to your Anthropic IdP app first login, they will receive the User role. This is the simplest automated option and requires no additional configuration beyond selecting "Just-in-Time (JIT)" as your provisioning mode.

For more control over provisioning, see Set up JIT or SCIM provisioning. You'll want to review this guide if you need to:

When your Identity Provider's X.509 signing certificate expires or is rotated, you'll need to update it in Claude or Console to maintain SSO functionality.

You can toggle Require SSO for Claude or Require SSO for Console off at any time. This will make SSO optional for all users.

To fully disconnect SSO, click “Manage SSO” then “Reset connection.” This will end all users’ sessions and require them to sign back in via email login link.

This guide covers how to add, remove, and manage the people on your Team or Enterprise plan.

For information on purchasing seats or adjusting your plan's seat allocation, see our guides for Team plans and Enterprise plans.

Admins and above can add members by following these steps:

This sends an email invitation to the person. The invitation expires after 21 days, so you'll need to re-invite them if they don't accept within that time period.

Add multiple members at once: You can invite multiple members by clicking "Bulk add" and typing or pasting email addresses separated by commas or new lines.

Members can also join your organization on their own through organization discovery. When you enable discoverability, colleagues with a matching email domain can find your organization during signup and request to join—no invitation needed. You can configure whether they're added automatically or require your approval. See Find and join a Team or Enterprise organization for details.

Admins and above can generate a shareable invite link and distribute it to teammates—for example, by posting it in a Slack channel, email thread, or team wiki—without needing to enter individual email addresses.

Availability:

To find and copy your invite link, navigate to Organization settings > Organization and access. New members who join via link are assigned to the lowest available seat tier, defaulting to a standard seat if none are available.

Admins can disable the link at any time—this immediately invalidates all existing links. Regenerating the link also invalidates the previous one.

For more details on how the joining flow works, see Join an organization via invite link.

Organizations with single sign-on (SSO) configured can automate member provisioning. Learn more about setting up SSO.

Organization members can invite teammates by email, even if they aren't admins. This makes it easier for your team to grow organically without requiring admin involvement for every new member.

Any member can access the invite flow from the account selector in Claude. They enter a teammate's email address and submit the invite. What happens next depends on your organization's new member approval setting:

Invites sent by members follow the same domain restrictions as other join methods — the invitee's email must match one of your organization's allowed domains.

Admins can enable or disable member-to-member invites from the admin settings. When disabled, only admins can send invitations. Invitees added through member invites are assigned the default member role and placed in the lowest available seat tier.

You can remove a member by navigating to Organization settings > Members, clicking the menu button to the right of the member, then selecting "Remove from team."

For Enterprise organizations using SCIM provisioning, members are automatically removed from Claude when they are removed from your Identity Provider.

When a member is removed:

Removing a member frees up their seat for reassignment, but does not automatically reduce your plan's total seat count. See our guides for Team plans and Enterprise plans for information on reducing seats.

Admins and above can export a CSV of your organization's current member list from your organization settings.

The export includes member details such as name, email address, role, and seat type. This is useful for auditing membership, reconciling seat usage, or maintaining an external record of your team.

To export:

You can resend an invite from Organization settings > Members. Click the “Pending” tab, find the member, and select to resend the invite.

You can revoke a pending invite from Organization settings > Members. Click the “Pending” tab, find the member, and select "Remove from team."

Yes. Once they join your team, they'll have both a personal account and a Team or Enterprise plan account. They can toggle between accounts through the menu by clicking their initials or name in the lower left corner.

To add a member that you previously removed, follow the same steps as adding a new member. Their account history will be maintained.

The current Primary Owner can transfer ownership by:

When Anthropic provides a new Enterprise organization and invites the Primary Owner, the same 21-day expiration period applies to that initial invitation. If your invitation has expired, please reach out to your account manager.