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.
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.
Summary
- Core Idea: Every seat in a workspace carries exactly one role, and that role determines what settings and data the person can see or change.
- Why It Matters: Getting roles wrong either creates unnecessary risk (too many admins) or unnecessary friction (people who cannot do their job because they lack access).
- Key Concepts: admin role, member role, billing role, workspace settings, seat.
- When to Use: When inviting a new person, auditing existing access, or deciding whether finance staff need admin rights just to see invoices.
- Limitations / Trade-offs: The role model is intentionally simple with three broad categories, not a fully custom permission system, so very specific access needs may not map cleanly onto one role.
- Related Topics: workspaces and seats, seat provisioning, workspace governance.
Foundations
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).
Mechanics & Interactions
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.
Advanced Considerations & Applications
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.
Common Misconceptions
- "Billing access requires admin rights." Billing is a separate, narrower role; a person can see invoices and cost data without also being able to manage members or settings.
- "Member is a second-class, restricted version of admin." Member is simply the role built for using Claude, not a limited admin; most people in a workspace should be members by design, not as a downgrade.
- "Roles are permanent once assigned." An admin can change any seat's role at any time; role assignment is a setting, not a fixed account type.
- "More admins means better coverage in case someone is unavailable." Extra admins add convenience but also add risk; a smaller, deliberate admin list is usually the safer trade-off.
- "Removing someone's role removes their seat." Changing a role does not remove the seat itself; removing access entirely requires removing the person from the workspace, not just downgrading their role.
FAQs
What are the three roles in a Claude Console workspace?
- Admin: full control over members, settings, and (on Enterprise) SSO/SCIM configuration.
- Member: uses Claude without managing access or settings.
- Billing: views invoices and cost data, without necessarily holding full admin rights.
Can someone hold more than one role at a time?
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.
Does the billing role also grant admin permissions?
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.
Who should default to the member role?
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.
How does role assignment interact with SSO on Enterprise plans?
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.
What happens if too many people are made admins?
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.
Does downgrading someone's role remove their seat?
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.
Can a billing-only person invite new members?
No. Inviting and removing members is an admin-level permission. Billing access is scoped to payment and cost visibility only.
Is the admin role the same across Team and Enterprise?
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.
How often should admin access be reviewed?
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.
What's the biggest mistake admins make with role assignment?
Defaulting to the admin role out of convenience rather than assigning member or billing access based on what the person actually needs to do.
Related
- How the Claude Console Organizes Workspaces, Seats, and Roles - the broader model that roles sit inside.
- Steps to Provision New Seats in the Claude Console - where role assignment happens in practice.
- How SSO and SCIM Provisioning Work Together - how Enterprise plans can automate role assignment via directory groups.
- Team & Enterprise Admin Best Practices - guidance on keeping role assignment deliberate over time.
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.