Teams are the fundamental building blocks for W&B access control, not individual users.
Let’s see how this plays out with a practical example. Imagine you have a project called image-classification and you want to grant two groups of people different levels of access:
data-scientists: They need to log runs, view results, and manage experiments.qa-engineers: They only need to view results and comment on runs.
Here’s how you’d set this up.
First, you create the teams. This is done via the W&B UI under "Settings" -> "Teams" or using the W&B CLI:
wandb teams create data-scientists
wandb teams create qa-engineers
Now, you add users to these teams. If a user alice@example.com is a data scientist, you’d add them like this:
wandb teams add-user data-scientists alice@example.com
And for a QA engineer bob@example.com:
wandb teams add-user qa-engineers bob@example.com
The real power comes from assigning permissions to these teams at the project level. You can do this in the W&B UI by navigating to your image-classification project, then "Settings" -> "Access Control".
For the data-scientists team, you’d grant them "Editor" role. This allows them to create, modify, and delete experiments, log data, and manage project settings.
For the qa-engineers team, you’d grant them "Viewer" role. This means they can see all runs, view dashboards, and add comments, but they cannot modify or delete anything.
This is how W&B RBAC works: you define roles (Viewer, Editor, Admin) and assign them to teams for specific projects. Individual users inherit permissions based on the teams they belong to.
The key internal mechanism is that W&B doesn’t store permissions per user per project. Instead, it maps users to teams, and then teams to projects with specific roles. When a user attempts an action, W&B checks their team memberships and the roles those teams have on the target project. This scales much better than managing individual user permissions for every project.
When you create a new project, say new-nlp-project, the data-scientists team might automatically be added as "Editor" and qa-engineers as "Viewer" if you have default project settings configured, or you’ll need to add them manually via the project’s "Access Control" settings.
The next thing you’ll likely want to explore is how to create custom roles if the built-in Viewer, Editor, and Admin aren’t granular enough for your needs.