The first user to sign up to W&B with a unique organization domain is assigned as that organization’s instance administrator role. The organization administrator assigns specific users team administrator roles.
W&B recommends to have more than one instance admin in an organization. It is a best practice to ensure that admin operations can continue when the primary admin is not available.
A team administrator is a user in organization that has administrative permissions within a team.
The organization administrator can access and use an organization’s account settings at https://wandb.ai/account-settings/ to invite users, assign or update a user’s role, create teams, remove users from your organization, assign the billing administrator, and more. See Add and manage users for more information.
Once an organization administrator creates a team, the instance administrator or ateam administrator can:
Invite users to that team or remove users from the team.
Assign or update a team member’s role.
Automatically add new users to a team when they join your organization.
Both the organization administrator and the team administrator use team dashboards at https://wandb.ai/<your-team-name> to manage teams. For more information on what organization administrators and team administrators can do, see Add and manage teams.
Limit visibility to specific projects
Define the scope of a W&B project to limit who can view, edit, and submit W&B runs to it. Limiting who can view a project is particularly useful if a team works with sensitive or confidential data.
An organization admin, team admin, or the owner of a project can both set and edit a project’s visibility.
The following workflow applies to users with instance administrator roles. Reach out to an administrator in your organization if you believe you should have instance administrator permissions.
In the upper right corner of the page, select the User menu dropdown. Within the Account section of the dropdown, select Settings.
Within the Settings tab, select General.
Select the Change name button.
Within the modal that appears, provide a new name for your organization and select the Save name button.
Add and manage users
As an administrator, use your organization’s dashboard to:
Invite or remove users.
Assign or update a user’s role.
Assign the billing administrator.
There are several ways an organization administrator can add users to an organization:
Member-by-invite
Auto provisioning with SSO
Domain capture
Seats and pricing
The proceeding table summarizes how seats work for Models and Weave:
Product
Seats
Cost based on
Models
Pay per set
How many Models paid seats you have, and how much usage you’ve accrued determines your overall subscription cost. Each user can be assigned one of the three available seat types: Full, Viewer, and No-Access
Weave
Free
Usage based
Invite a user
Administrators can invite users to their organization, as well as specific teams within the organization.
In the upper right corner of the page, select the User menu dropdown. Within the Account section of the dropdown, select Users.
Select Invite new user.
In the modal that appears, provide the email or username of the user in the Email or username field.
(Recommended) Add the user to a team from the Choose teams dropdown menu.
From the Select role dropdown, select the role to assign to the user. You can change the user’s role at a later time. See the table listed in Assign a role for more information about possible roles.
Choose the Send invite button.
W&B sends an invite link using a third-party email server to the user’s email after you select the Send invite button. A user can access your organization once they accept the invite.
Navigate to https://<org-name>.io/console/settings/. Replace <org-name> with your organization name.
Select the Add user button
Within the modal that appears, provide the email of the new user in the Email field.
Select a role to assign to the user from the Role dropdown. You can change the user’s role at a later time. See the table listed in Assign a role for more information about possible roles.
Check the Send invite email to user box if you want W&B to send an invite link using a third-party email server to the user’s email.
Select the Add new user button.
Auto provision users
A W&B user with matching email domain can sign in to your W&B Organization with Single Sign-On (SSO) if you configure SSO and your SSO provider permits it. SSO is available for all Enterprise licenses.
Enable SSO for authentication
W&B strongly recommends and encourages that users authenticate using Single Sign-On (SSO). Reach out to your W&B team to enable SSO for your organization.
To learn more about how to setup SSO with Dedicated cloud or Self-managed instances, refer to SSO with OIDC or SSO with LDAP.
W&B assigned auto-provisioning users “Member” roles by default. You can change the role of auto-provisioned users at any time.
Auto-provisioning users with SSO is on by default for Dedicated cloud instances and Self-managed deployments. You can turn off auto provisioning. Turning auto provisioning off enables you to selectively add specific users to your W&B organization.
The proceeding tabs describe how to turn off SSO based on deployment type:
Reach out to your W&B team if you are on Dedicated cloud instance and you want to turn off auto provisioning with SSO.
Use the W&B Console to turn off auto provisioning with SSO:
Navigate to https://<org-name>.io/console/settings/. Replace <org-name> with your organization name.
Choose Security
Select the Disable SSO Provisioning to turn off auto provisioning with SSO.
Auto provisioning with SSO is useful for adding users to an organization at scale because organization administrators do not need to generate individual user invitations.
Domain capture
Domain capture helps your employees join the your companies organization to ensure new users do not create assets outside of your company jurisdiction.
Domains must be unique
Domains are unique identifiers. This means that you can not use a domain that is already in use by another organization.
Domain capture lets you automatically add people with a company email address, such as @example.com, to your W&B SaaS cloud organization. This helps all your employees join the right organization and ensures that new users do not create assets outside of your company jurisdiction.
This table summarizes the behavior of new and existing users with and without domain capture enabled:
With domain capture
Without domain capture
New users
Users who sign up for W&B from verified domains are automatically added as members to your organization’s default team. They can choose additional teams to join at sign up, if you enable team joining. They can still join other organizations and teams with an invitation.
Users can create W&B accounts without knowing there is a centralized organization available.
Invited users
Invited users automatically join your organization when accepting your invite. Invited users are not automatically added as members to your organization’s default team. They can still join other organizations and teams with an invitation.
Invited users automatically join your organization when accepting your invite. They can still join other organizations and teams with an invitation.
Existing users
Existing users with verified email addresses from your domains can join your organization’s teams within the W&B App. All data that existing users create before joining your organization remains. W&B does not migrate the existing user’s data.
Existing W&B users may be spread across multiple organizations and teams.
To automatically assign non-invited new users to a default team when they join your organization:
In the upper right corner of the page, select the User menu dropdown. From the dropdown, choose Settings.
Within the Settings tab, select General.
Choose the Claim domain button within Domain capture.
Select the team that you want new users to automatically join from the Default team dropdown. If no teams are available, you’ll need to update team settings. See the instructions in Add and manage teams.
Click the Claim email domain button.
You must enable domain matching within a team’s settings before you can automatically assign non-invited new users to that team.
Navigate to the team’s dashboard at https://wandb.ai/<team-name>. Where <team-name> is the name of the team you want to enable domain matching.
Select Team settings in the global navigation on the left side of the team’s dashboard.
Within the Privacy section, toggle the “Recommend new users with matching email domains join this team upon signing up” option.
Reach out to your W&B Account Team if you use Dedicated or Self-managed deployment type to configure domain capture. Once configured, your W&B SaaS instance automatically prompts users who create a W&B account with your company email address to contact your administrator to request access to your Dedicated or Self-managed instance.
With domain capture
Without domain capture
New users
Users who sign up for W&B on SaaS cloud from verified domains are automatically prompted to contact an administrator with an email address you customize. They can still create an organizations on SaaS cloud to trial the product.
Users can create W&B SaaS cloud accounts without learning their company has a centralized dedicated instance.
Existing users
Existing W&B users may be spread across multiple organizations and teams.
Existing W&B users may be spread across multiple organizations and teams.
Assign or update a user’s role
Every member in an Organization has an organization role and seat for both W&B Models and Weave. The type of seat they have determines both their billing status and the actions they can take in each product line.
You initially assign an organization role to a user when you invite them to your organization. You can change any user’s role at a later time.
A user within an organization can have one of the proceeding roles:
Role
Descriptions
Administrator
A instance administrator who can add or remove other users to the organization, change user roles, manage custom roles, add teams and more. W&B recommends ensuring there is more than one administrator in the event that your administrator is unavailable.
Member
A regular user of the organization, invited by an instance administrator. A organization member cannot invite other users or manage existing users in the organization.
Viewer (Enterprise-only feature)
A view-only user of your organization, invited by an instance administrator. A viewer only has read access to the organization and the underlying teams that they are a member of.
Custom Roles (Enterprise-only feature)
Custom roles allow organization administrators to compose new roles by inheriting from the preceding View-Only or Member roles, and adding additional permissions to achieve fine-grained access control. Team administrators can then assign any of those custom roles to users in their respective teams.
In the upper right corner of the page, select the User menu dropdown. From the dropdown, choose Users.
Provide the name or email of the user in the search bar.
Select a role from the TEAM ROLE dropdown next to the name of the user.
Assign or update a user’s access
A user within an organization has one of the proceeding model seat or weave access types: full, viewer, or no access.
Seat type
Description
Full
Users with this role type have full permissions to write, read, and export data for Models or Weave.
Viewer
A view-only user of your organization. A viewer only has read access to the organization and the underlying teams that they are a part of, and view only access to Models or Weave.
No access
Users with this role have no access to the Models or Weave products.
Model seat type and weave access type are defined at the organization level, and inherited by the team. If you want to change a user’s seat type, navigate to the organization settings and follow the proceeding steps:
For SaaS users, navigate to your organization’s settings at https://wandb.ai/account-settings/<organization>/settings. Ensure to replace the values enclosed in angle brackets (<>) with your organization name. For other Dedicated and Self-managed deployments, navigate to https://<your-instance>.wandb.io/org/dashboard.
Select the Users tab.
From the Role dropdown, select the seat type you want to assign to the user.
The organization role and subscription type determines which seat types are available within your organization.
Select Create a team to collaborate on the left navigation panel underneath Teams.
Provide a name for your team in the Team name field in the modal that appears.
Choose a storage type.
Select the Create team button.
After you select Create team button, W&B redirects you to a new team page at https://wandb.ai/<team-name>. Where <team-name> consists of the name you provide when you create a team.
Once you have a team, you can add users to that team.
Invite users to a team
Invite users to a team in your organization. Use the team’s dashboard to invite users using their email address or W&B username if they already have a W&B account.
Navigate to https://wandb.ai/<team-name>.
Select Team settings in the global navigation on the left side of the dashboard.
Select the Users tab.
Choose on Invite a new user.
Within the modal that appears, provide the email of the user in the Email or username field and select the role to assign to that user from the Select a team role dropdown. For more information about roles a user can have in a team, see Team roles.
Match members to a team organization during sign up
Allow new users within your organization discover Teams within your organization when they sign-up. New users must have a verified email domain that matches your organization’s verified email domain. Verified new users can view a list of verified teams that belong to an organization when they sign up for a W&B account.
An organization administrator must enable domain claiming. To enable domain capture, see the steps described in Domain capture.
Assign or update a team member’s role
Select the account type icon next to the name of the team member.
From the drop-down, choose the account type you want that team member to posses.
This table lists the roles you can assign to a member of a team:
Role
Definition
Administrator
A user who can add and remove other users in the team, change user roles, and configure team settings.
Member
A regular user of a team, invited by email or their organization-level username by the team administrator. A member user cannot invite other users to the team.
View-Only (Enterprise-only feature)
A view-only user of a team, invited by email or their organization-level username by the team administrator. A view-only user only has read access to the team and its contents.
Service (Enterprise-only feature)
A service worker or service account is an API key that is useful for utilizing W&B with your run automation tools. If you use an API key from a service account for your team, ensure to set the environment variable WANDB_USERNAME to correctly attribute runs to the appropriate user.
Custom Roles (Enterprise-only feature)
Custom roles allow organization administrators to compose new roles by inheriting from the preceding View-Only or Member roles, and adding additional permissions to achieve fine-grained access control. Team administrators can then assign any of those custom roles to users in their respective teams. Refer to this article for details.
Only enterprise licenses on Dedicated cloud or Self-managed deployment can assign custom roles to members in a team.
Remove users from a team
Remove a user from a team using the team’s dashboard. W&B preserves runs created in a team even if the member who created the runs is no longer on that team.
Navigate to https://wandb.ai/<team-name>.
Select Team settings in the left navigation bar.
Select the Users tab.
Hover your mouse next to the name of the user you want to delete. Select the ellipses or three dots icon (…) when it appears.
From the dropdown, select Remove user.
2 - Manage access control for projects
Manage project access using visibility scopes and project-level roles
Define the scope of a W&B project to limit who can view, edit, and submit W&B runs to it.
You can use a combination of a couple of controls to configure the access level for any project within a W&B team. Visibility scope is the higher-level mechanism. Use that to control which groups of users can view or submit runs in a project. For a project with Team or Restricted visibility scope, you can then use Project level roles to control the level of access that each user has within the project.
The owner of a project, a team admin, or an organization admin can set or edit a project’s visibility.
Visibility scopes
There are four project visibility scopes you can choose from. In order of most public to most private, they are:
Scope
Description
Open
Anyone who knows about the project can view it and submit runs or reports.
Public
Anyone who knows about the project can view it. Only your team can submit runs or reports.
Team
Only members of the parent team can view the project and submit runs or reports. Anyone outside the team can not access the project.
Restricted
Only invited members from the parent team can view the project and submit runs or reports.
Set a project’s scope to Restricted if you would like to collaborate on workflows related to sensitive or confidential data. When you create a restricted project within a team, you can invite or add specific members from the team to collaborate on relevant experiments, artifacts, reports, and so forth.
Unlike other project scopes, all members of a team do not get implicit access to a restricted project. At the same time, team admins can join restricted projects if needed.
Set visibility scope on a new or existing project
Set a project’s visibility scope when you create a project or when editing it later.
Only the owner of the project or a team admin can set or edit its visibility scope.
When a team admin enables Make all future team projects private (public sharing not allowed) within a team’s privacy setting, that turns off Open and Public project visibility scopes for that team. In this case, your team can only use Team and Restricted scopes.
Set visibility scope when you create a new project
Navigate to your W&B organization on SaaS Cloud, Dedicated Cloud, or Self-managed instance.
Click the Create a new project button in the left hand sidebar’s My projects section. Alternatively, navigate to the Projects tab of your team and click the Create new project button in the upper right hand corner.
After selecting the parent team and entering the name of the project, select the desired scope from the Project Visibility dropdown.
Complete the following step if you select Restricted visibility.
Provide names of one or more W&B team members in the Invite team members field. Add only those members who are essential to collaborate on the project.
You can add or remove members in a restricted project later, from its Users tab.
Edit visibility scope of an existing project
Navigate to your W&B Project.
Select the Overview tab on the left column.
Click the Edit Project Details button on the upper right corner.
From the Project Visibility dropdown, select the desired scope.
Complete the following step if you select Restricted visibility.
Go to the Users tab in the project, and click Add user button to invite specific users to the restricted project.
All members of a team lose access to a project if you change its visibility scope from Team to Restricted, unless you invite the required team members to the project.
All members of a team get access to a project if you change its visibility scope from Restricted to Team.
If you remove a team member from the user list for a restricted project, they lose access to that project.
Other key things to note for restricted scope
If you want to use a team-level service account in a restricted project, you should invite or add that specifically to the project. Otherwise a team-level service account can not access a restricted project by default.
You can not move runs from a restricted project, but you can move runs from a non-restricted project to a restricted one.
You can convert the visibility of a restricted project to only Team scope, irrespective of the team privacy setting Make all future team projects private (public sharing not allowed).
If the owner of a restricted project is not part of the parent team anymore, the team admin should change the owner to ensure seamless operations in the project.
Project level roles
For the Team or Restricted scoped projects in your team, you can assign a specific role to a user, which could be different from that user’s team level role. For example, if a user has Member role at the team level, you can assign the View-Only, or Admin, or any available custom role to that user within a Team or Restricted scope project in that team.
Project level roles are in preview on SaaS Cloud, Dedicated Cloud, and Self-managed instances.
Assign project level role to a user
Navigate to your W&B Project.
Select the Overview tab on the left column.
Go to the Users tab in the project.
Click the currently assigned role for the pertinent user in the Project Role field, which should open up a dropdown listing the other available roles.
Select another role from the dropdown. It should save instantly.
When you change the project level role for a user to be different from their team level role, the project level role includes a * to indicate the difference.
Other key things to note for project level roles
By default, project level roles for all users in a team or restricted scoped project inherit their respective team level roles.
You can not change the project level role of a user who has View-only role at the team level.
If the project level role for a user within a particular project is same as the team level role, and at some point if a team admin changes the team level role, the relevant project role is automatically changed to track the team level role.
If you change the project level role for a user within a particular project such that it is different from the team level role, and at some point if a team admin changes the team level role, the relevant project level role remains as is.
If you remove a user from a restricted project when their project level role was different from the team level role, and if you then add the user back to the project after some time, they would inherit the team level role due to the default behavior. If needed, you would need to change the project level role again to be different from the team level role.
