How Roles and Permissions Control Workspace Access
Once a workspace has more than one person in it, someone has to decide who can invite new members, who can change settings, and who can see the bill.
//
Search across all documentation pages
Once a workspace has more than one person in it, someone has to decide who can invite new members, who can change settings, and who can see the bill.
The Claude Console answers this with three roles: admin, member, and billing.
Each role is a bundle of permissions attached to a seat, and understanding what each bundle actually includes is the difference between a workspace that runs smoothly and one where people either have too much power or not enough.
The admin role is the most powerful of the three.
An admin can invite and remove members, change any other member's role, configure workspace-wide settings, and, on Enterprise plans, set up SSO and SCIM provisioning.
Admin is the role automatically assigned to whoever creates a workspace, and it is meant for the small group of people who are actually responsible for running that workspace.
The member role is the default for most people in a workspace.
A member can use Claude according to whatever the workspace allows, but cannot invite or remove anyone else, cannot see billing, and cannot change workspace settings.
Most employees using Claude day to day only need the member role.
The billing role is narrower and more specialized than either admin or member.
A person with billing access can view invoices, payment details, and usage-driven cost information, without necessarily being able to manage who else has a seat or change workspace settings.
This role exists specifically so that finance staff can do their job without also being handed the ability to change who has access to the company's Claude workspace.
A useful way to think about these three roles is as three separate questions a workspace needs answered: who runs it (admin), who uses it (member), and who pays for it (billing).
Roles are not stackable accounts; a seat holds exactly one role at a time, though an admin can change a seat's role whenever appropriate.
This means promoting someone from member to admin, or from admin down to member, is a single settings change rather than creating a new seat.
Billing access interacts with the other two roles in a specific way: it can be granted on its own, separate from admin, but a workspace's admins always retain visibility into billing as part of their broader permissions.
In other words, billing-only access is a subtraction from full admin rights, not an entirely separate track.
Role changes take effect immediately once saved, which matters for offboarding.
When someone leaves the company, downgrading or removing their role, or removing their seat entirely, is what actually revokes their access, not just deactivating their broader company account (unless SSO and SCIM automation is configured to do that automatically, which is covered on the SSO and SCIM page in this section).
A common interaction to watch for is over-provisioning the admin role.
Because admin access is convenient, it is tempting to make everyone who asks for it an admin rather than figuring out whether they actually need member or billing access instead.
Over time this quietly expands the number of people who could, intentionally or accidentally, change workspace-wide settings or remove other people's access.
At small scale, with a handful of people, loose role assignment rarely causes problems because everyone already knows and trusts each other.
At larger scale, especially on Enterprise plans with dozens or hundreds of seats, the number of admins becomes a real governance question, similar to how a company would think about who holds root access to a production system.
A useful practice, covered in more depth in this section's best practices page, is treating the admin role as something granted deliberately and reviewed periodically, rather than something handed out by default.
| Role | Strength | Weakness | Best Fit |
|---|---|---|---|
| Admin | Full control over people, settings, and (Enterprise) SSO/SCIM | Highest risk if overused or compromised | The small group actually responsible for running the workspace |
| Member | Simple, no risk of accidental settings changes | Cannot see billing or manage other members | The majority of day-to-day Claude users |
| Billing | Narrow, purpose-built for finance visibility | Cannot invite, remove, or reconfigure members | Finance or accounting staff who need invoice visibility only |
On Enterprise plans, roles interact with SSO in a further way: identity providers can sometimes be configured to map certain directory groups to certain Claude roles, so that, for example, everyone in an "IT-Admins" group in the company directory is automatically granted the admin role in the Claude workspace, keeping role assignment consistent with how the rest of the company's tools are governed.
This reduces the manual role-assignment work an admin would otherwise have to repeat by hand for every new hire.
No. Each seat holds exactly one role at a time, though an admin can change that role whenever it makes sense, such as promoting a member to admin.
No. Billing is intentionally narrower than admin. A person with billing access can see payment and cost details without being able to invite, remove, or reconfigure other members.
Most people using Claude for day-to-day work. Member is the role built for actual usage, not a restricted fallback, and it is the right choice unless someone specifically needs to manage the workspace or see billing.
Identity providers can sometimes map company directory groups to Claude roles, so a group like "IT-Admins" automatically receives the admin role, keeping role assignment consistent with how the rest of the company manages access.
The workspace accumulates unnecessary risk, since any admin can change settings or member access. A smaller, deliberately maintained admin list is easier to reason about and audit.
No. Changing a role is separate from removing a seat. To fully revoke access, an admin needs to remove the person from the workspace, not just change their role.
No. Inviting and removing members is an admin-level permission. Billing access is scoped to payment and cost visibility only.
The core admin permissions are similar, but Enterprise admins additionally have access to SSO/SCIM configuration and the Enterprise Analytics API, which Team admins do not.
There is no fixed rule, but treating it as a periodic review, similar to any other privileged access review, catches accounts that no longer need admin rights before they become a real risk.
Defaulting to the admin role out of convenience rather than assigning member or billing access based on what the person actually needs to do.
Stack versions: Written against the Claude model lineup current as of ~June 2026 - Claude Fable 5, Claude Opus 4.8, Claude Sonnet 5 (the default), and Claude Haiku 4.5. Model names, pricing, and product features move quickly - verify current specifics at platform.claude.com/docs before relying on them.
Reviewed by Chris St. John·Last updated Jul 16, 2026