Built-in Roles

A vs B ships with five built-in roles: Owner, Admin, Developer, Collaborator, and Viewer. Each role grants a set of permissions. Permissions control what a member can see and do inside your organization.

The five built-in roles

Owner

The Owner is the account that created the organization. Every organization has exactly one Owner. The Owner has full access to everything: every project, every setting, every experiment, billing, and member management.

You cannot change the Owner's permissions, remove the Owner from the organization, or delete the Owner role. The Owner can hand the organization to another member, from the Members tab. See Transferring ownership.

Admin

Admin has every permission turned on by default, the same as Owner. In practice Admin can do everything Owner can: manage billing, change organization settings, and manage members and roles, the same way Owner does. Assign Admin to trusted team leads who need full operational control but do not need to hold the one Owner slot.

The real difference is structural, not functional. The Owner role's permissions are locked and can never change. Admin's permissions can be turned off, one at a time, by an Owner or another Admin. See Editing a built-in role below.

Developer

Developers can edit project settings, create and edit experiments (including the JavaScript and CSS that runs in them), view reports, and export data. They cannot publish experiments to production. They also cannot manage projects, team members, or roles. This role suits engineers who build and test experiments but hand the final launch to a lead.

Collaborator

Collaborators can create experiments and view reports. They cannot edit project settings, write code for a variation (one specific version being tested, control or a challenger), or publish to production. This role fits product managers, designers, or marketers who define experiments but rely on developers to build and ship them.

Viewer

Viewers have read-only access. They can view reports and read project configurations, but they cannot make any changes. This role suits stakeholders who need visibility into what is being tested, without needing to act on it.

Permissions by role

The table below shows which of the ten permissions each built-in role includes. A checkmark means the permission is granted.

When your role does not include a permission

The dashboard hides what your role cannot do. Without Manage Projects, for example, the Projects page has no New Project button. If an action is refused anyway, the message names the permission you need, such as "You need the Manage Projects permission to do this. An Owner or Admin can give it to you."

Organization Settings is only for the Owner and Admins. If you open a link to it with another role, you land on the Projects page with a note saying why.

Editing a built-in role

Only the Owner role is locked. Every other built-in role, Admin, Developer, Collaborator, and Viewer, can have any of its ten permissions turned on or off. Do this from Settings, Roles. Turning a permission off changes it for every member on that role in your organization, not just one person.

The short description of each role, on the Members tab, in the invite dialog and in Settings, Roles, is written from the role's current permissions. Edit a role and its description changes with it, so it always says what that role can do in your organization.

You need your organization's Custom Roles entitlement to edit any role, built-in or custom. Without it, roles in Settings, Roles show their defaults and cannot be changed.

If none of the five built-in roles fit your team, even after adjusting their permissions, create a custom role instead.

Assigning roles

You assign a role when you invite a member. To change a member's role later, see Managing Members.