Summary and recommendation
Weights & Biases user management can be run manually, but complexity usually increases with role models, licensing gates, and offboarding dependencies. This guide gives the exact mechanics and where automation has the biggest impact.
Weights & Biases organizes access through a two-tier hierarchy: organization-level roles (Admin, Member, Viewer) govern who belongs to the org, while team-level roles (Admin, Member, Viewer) govern what users can do within a specific team.
Custom roles are available on Enterprise and allow per-permission granularity beyond the defaults.
Because org membership and team membership are managed separately, adding someone to the organization does not automatically grant them access to any project.
Quick facts
| Admin console path | Organization Settings → Members (accessible via wandb.ai/<org-name>/settings) |
| Admin console URL | Official docs |
| SCIM available | Yes |
| SCIM tier required | Enterprise |
| SSO prerequisite | No |
User types and roles
| Role | Permissions | Cannot do | Plan required | Seat cost | Watch out for |
|---|---|---|---|---|---|
| Organization Admin | Full control over organization settings, billing, member management, team creation, and role assignment. Can invite and remove members, assign roles, and configure SSO/SCIM. | All plans | At least one Organization Admin must exist at all times; the last admin cannot be removed. | ||
| Organization Member | Can be added to teams, create projects within teams they belong to, and run experiments. Default role for invited users. | Cannot manage organization-level settings, billing, or invite other members to the organization. | All plans | Members consume a paid seat on Pro and Enterprise plans. | |
| Viewer (Organization-level) | Read-only access to organization resources. Can view runs, reports, and artifacts but cannot create or modify them. | Cannot create runs, reports, or artifacts; cannot modify any settings. | All plans | Viewer seats may be billed differently from full member seats on Enterprise; confirm with W&B sales. | |
| Team Admin | Can manage team membership, team settings, and team-level role assignments within their specific team. | Cannot manage organization-level settings or billing. | All plans | Team Admin role is scoped to the team; does not grant organization-wide admin privileges. | |
| Team Member | Can create and manage runs, reports, and artifacts within the team's projects. | Cannot manage team membership or settings unless also a Team Admin. | All plans | ||
| Custom Role | Administrator-defined permission set based on predefined role templates with specific permissions added or removed. | Capabilities depend on how the custom role is configured. | Enterprise | Custom roles are only available on Enterprise plans and must be created by an Organization Admin. |
Permission model
- Model type: hybrid
- Description: W&B uses a hierarchical role-based model with roles at the organization level and team level. Organization-level roles (Admin, Member, Viewer) govern overall access; team-level roles (Admin, Member, Viewer) govern access within a specific team. Custom roles are available on Enterprise to extend or restrict default role permissions.
- Custom roles: Yes
- Custom roles plan: Enterprise
- Granularity: Role assignments at organization scope and team scope; project-level visibility can be set to public, private, or team-only. Custom roles allow per-permission granularity within Enterprise.
How to add users
- Navigate to wandb.ai/
/settings and select the 'Members' tab. - Click 'Invite members'.
- Enter the invitee's email address.
- Select the organization-level role to assign (Admin, Member, or Viewer).
- Click 'Send invite'. The invitee receives an email to accept and create or link their W&B account.
- Optionally, add the new member to one or more teams from the Teams tab after they accept the invite.
Required fields: Email address, Organization role selection
Watch out for:
- Invitees must accept the email invitation before they appear as active members.
- Inviting a user does not automatically add them to any team; team membership must be configured separately.
- On self-hosted (dedicated cloud / on-premises) deployments, domain-based auto-provisioning behavior may differ from SaaS.
- Seat limits may apply depending on plan; exceeding limits may require a plan upgrade or contacting W&B sales.
| Bulk option | Availability | Notes |
|---|---|---|
| CSV import | No | Not documented |
| Domain whitelisting | Yes | Automatic domain-based user add |
| IdP provisioning | Yes | Enterprise |
How to remove or deactivate users
- Can delete users: Unknown
- Delete/deactivate behavior: Manual admin flows emphasize removing a member or deactivating access, while the SCIM API surface also exposes DELETE. Treat irreversible deletion behavior as workflow-specific and confirm before using it for production offboarding.
- Navigate to wandb.ai/
/settings and select the 'Members' tab. - Locate the member to remove.
- Click the options menu (three dots) next to the member's name.
- Select 'Remove from organization'.
- Confirm the removal. The user immediately loses access to the organization.
| Data impact | Behavior |
|---|---|
| Owned records | Runs, artifacts, and reports created by the removed user remain in the organization and are still accessible to other members with appropriate permissions. |
| Shared content | Shared reports and artifacts remain accessible to team members who had prior access. |
| Integrations | API keys associated with the removed user are invalidated; any automated pipelines using that user's API key will stop functioning. |
| License freed | Removing a member frees the seat, making it available for a new invite. Billing adjustments depend on the plan billing cycle; confirm with W&B billing. |
Watch out for:
- API keys belonging to the removed user are invalidated immediately; update any CI/CD or automated scripts that use that user's key before removal.
- If the removed user was the sole admin of a team, team admin responsibilities should be reassigned before removal.
- SCIM-based deprovisioning (Enterprise) can automate removal when the user is deactivated in the IdP.
License and seat management
| Seat type | Includes | Cost |
|---|---|---|
| Full Member seat | Full read/write access to runs, artifacts, reports, and team features. | Included in Pro ($50–150/user/mo usage-based) and Enterprise (custom, ~$315–400/seat/mo typical) plans. |
| Viewer seat | Read-only access to runs, reports, and artifacts. | May be available at reduced cost on Enterprise; confirm with W&B sales. |
- Where to check usage: wandb.ai/
/settings → 'Members' tab shows current member count; billing details available under 'Billing' section of organization settings. - How to identify unused seats: No built-in 'last active' or inactivity report is documented in official help docs. Admins can review member list manually or use SCIM audit logs on Enterprise to identify inactive accounts.
- Billing notes: Free plan is for personal use only and does not support multi-user organizations in the same way. Pro plan is usage-based per user. Enterprise pricing is custom and seat-based; Viewer seats may be priced differently. Pricing figures in this record are sourced from the context seed and should be verified directly with W&B sales or the current pricing page.
The cost of manual management
Every app in your stack that lacks automated provisioning creates the same recurring overhead: manual invites, ad-hoc removal requests, and no reliable signal for unused seats. W&B compounds this because there is no built-in last-active or inactivity report - admins must audit the member list manually or cross-reference SCIM logs on Enterprise.
Viewer seats may be priced differently from full Member seats on Enterprise, so unreviewed seat assignments carry direct cost risk. Custom roles, which are the only way to restrict permissions below the default role set, are locked to Enterprise, meaning Pro-plan teams have no granular access control path.
What IT admins are saying
Community evidence is not specific enough to quote or summarize yet for this app.
The decision
Manual management is workable for small, stable teams where org membership rarely changes and every app in the ML stack is managed by the same admin. It becomes a liability when headcount scales, when contractor or vendor access needs time-bounding, or when compliance requires an auditable provisioning trail.
The lack of inactivity reporting means seat hygiene depends entirely on admin discipline rather than tooling. Teams on Enterprise with an IdP already in place should evaluate SCIM provisioning before the member list grows beyond easy manual oversight.
Bottom line
W&B's manual access controls are functional but sparse: the two-tier org/team model is logical, invite flows are straightforward, and removal is immediate.
The gaps - no activity reporting, no grace period on API key invalidation, and custom roles gated to Enterprise - mean that manual management works until it doesn't.
For any team where seat cost, compliance, or pipeline stability matters, the manual approach introduces risk that compounds quietly over time.
Automate Weights & Biases workflows without one-off scripts
Stitchflow builds and maintains end-to-end IT automation across your SaaS stack, including apps without APIs. Built for exactly how your company works, with human approvals where they matter.
