Teams are an Enterprise-only feature. If you are on the Developer or Pro tiers, this guide will not apply to you. To upgrade to Enterprise, feel free to reach out to our team here.
For larger organizations, the Teams feature enables an organizational and settings/ permissions layer on top of a Project. Teams are configured at the Project (not Organization) level, and are default-editable by all Project Admins.Once teams are configured and a user is assigned to a team, any config (gates/ experiments/ metrics, etc.) they create will be associated with the team they belong to, and will inherit the settings of that team. Users who are members of multiple teams will have the choice of which team to associate their config with at creation time.
To create a team, navigate to Settings -> People -> Teams. Create a new team via the +Create button, where you’ll be asked to name the team and add members. You can add/ remove members from a team at any time, not just at initial team creation.Each team has a Members page and a Settings page. Within Members you can see all members of the team, including the team members project role and team role (which can be member or admin). Team members can be promoted or removed.
At the Project-level, you can require all config creations are associated with a team via the “Require teams” setting under Settings -> Product Configuration -> General. Note that this will block anyone who isn’t yet assigned to a team from creating a config, so should only be enabled after all members of the project have been added to (at least) one team.
Within each team, there are a number of settings you can configure:Default Monitoring Metrics/ Scorecard Metrics: This setting enables pre-configuration of a set of metrics to add to every new gate/ experiment/ holdout at the team level. These might be a mix of top-line company metrics every team must monitor (e.g. revenue/ app performance), as well as a set of team-specific KPIs all rollouts and experiments should be tracking.
Require Reviews: If reviews are not already required at the Project-level, this setting enables you to require reviews at the individual team level. Note that this setting won’t appear if you’re already requiring reviews at the Project level (controlled via Settings -> Product Configuration -> Reviews).
Default Allowed Reviewers: This setting enables more granular control of who is allowed to review and approve changes to a team’s configs. There are three options here- “Anyone in the Project” (least restrictive), “Team Members Only” (keep reviews within the team), and “Team or Project Admins Only” (most restrictive).Note that team-based review configurations layer on top of role-based review settings. For example, if your role has permission to approve reviews and your team has review settings set to “Team members only”, then an approver would need to both be in a role with review approval permission AND be on the team to approve a review pending for that team’s config.
Create/ Edit Configs and Metrics: This setting dictates which members of a team are allowed to edit or create configs tagged with the team. There are two options here- “Anyone in the Project” (no restrictions, anyone can edit the team’s configs), or “Team Members Only”.
Default Target Applications: This setting will auto-apply any assigned Target Applications to all configs created that are associated with this team. Note that this only impacts which Target Applications are added to the config by default at creation time, but can be edited/ overridden as needed.
Default Holdout: It’s a common use-case for teams to want to measure cumulative impact of their new features/ experiments over the course of a Quarter/ Half, etc. To make this easier and more automatic, you can associate a default Holdout to a team. This will cause all subsequent configs associated with the team will be auto-added to this default Holdout.
Once a user is associated with a team, every config they create will now be default-associated with their team. For users on multiple teams, they will be able to choose which team to associate their config with at creation time. This will apply the team’s relevant settings to that config.
Every config will have a field in the header for “Team”. This field is separate from “Owner”- whereby “Owner” is a single individual, “Team” is a group of individuals and will not automatically update if, for example, the Owner moves to a different team within the organization. Teams must be manually changed (subject to the review requirements) at the config level.
Finally, with the addition of teams, every user can now filter Gate/ Experiment/ Metric lists and the Home Feed by team. The Home Feed will default to a user’s team(s), ensuring the most relevant content is surfaced.
