# Teams

URL: https://select.dev/docs/reference/using-select/access-management/teams
Index of all SELECT docs: https://select.dev/docs/llms.txt

> Learn how to create and manage teams for simplified permissions and collaborative resource ownership.

SELECT uses teams to simplify permission management, enable collaborative ownership of resources, and integrate with SSO group mappings.

## Teams Overview

![SELECT team settings](https://select.dev/cdn-cgi/imagedelivery/1zmOcgV1p520E4lLTrYjjg/f8eeedfa-919b-454d-d8fe-9d1518ad2a00/width=3456,quality=75)

**Teams** play three key roles in SELECT:

1. They are an abstraction which streamline permissions management for a group of users. Roles can be granted to a team, and then users added to that team to inherit the roles.
2. They act as owners for editable objects, currently just [Monitors](https://select.dev/docs/monitors).
3. For users with SSO enabled, they are the mechanism by which SSO groups are mapped to SELECT users.

## Team Membership Types

When adding a user to a **team**, there are three kinds of access: `Viewer`, `Editor`,  and `Admin`. `Viewer` membership will grant the user only read access to any editable objects owned by the team. `Editor` membership will grant the user edit access to any editable objects owned by the team. `Admin` membership will grant the user everything Editor does plus managing the teams settings and other team members.

#### Team Admins

A Team Admin administers one team: the team the role was granted on. On that team they can:

- Rename it, and change the role new members receive by default.
- Delete it.
- Add and remove members, and add and remove the SSO groups mapped to it.
- Change the role a member holds, including promoting another member to Admin.
- Grant and revoke roles on the team, within the limits described below.

A Team Admin cannot:

- Do any of the above on a team they do not administer.
- Create a new team. That requires the Team Creator role, or the Admin role on the SELECT Organization.
- Mark a team as the All Users team, or remove that marking. That is a statement about the whole organization, so it requires the Admin role on the SELECT Organization.
- Grant the team a role that gives more access than the Team Admin already holds. In practice this means a Team Admin cannot widen their own team’s access to data. Granting the team an account role, a usage group role, or a role on the SELECT Organization is rejected.

Team membership grants no access to usage data on its own. A team’s access to data comes from the roles granted to the team, which every member inherits.

![SELECT team settings](https://select.dev/cdn-cgi/imagedelivery/1zmOcgV1p520E4lLTrYjjg/abeb089d-5f1b-49ab-4e65-bd7a72f12100/width=3456,quality=75)

## Team Ownership of Monitors and Other Editable Objects

By default, newly created [Monitors](https://select.dev/docs/monitors) are owned by the SELECT organization. This means they can only be seen by users with `Viewer` access (or higher) on the SELECT Organization, and they can only be edited by users with `Editor` access (or higher) on SELECT Organization.

To facilitate the creation of monitors by users who may not have full access to the whole SELECT Organization, monitors can also be owned by a **team**. Where monitors are owned by a team, they are subject to the same read permissions as that team. For example, if a team has only `Viewer` access to the _Sales_ Usage Group, then any monitors owned by that team will also only be able to monitor usage data tagged with the _Sales_ Usage Group.

![SELECT team settings](https://select.dev/cdn-cgi/imagedelivery/1zmOcgV1p520E4lLTrYjjg/c700553a-8863-482c-8384-2e863a7dc200/width=3456,quality=75)

## Example: Data Platform Team

A central data platform team manages several Snowflake Accounts for different business units. They want to be able to restrict security and team management to only a few select users, but also allow everyone in the central team to be able to view usage data within all of the business unit accounts.

In this scenario we would recommend:

- Create a **Team** called _Data Platform Team_. Use an SSO group mapping to automatically add users to the team.
- Grant the **Data Platform Team** the **Editor** role on the **SELECT Organization**. This role will grant them the ability to view usage data across all accounts and create any resources within SELECT such as monitors and usage groups without having to manage individual grants on each account.
- Grant the few specific users who need to manage users and teams the **Admin** role on the **SELECT Organization**. You could do this directly, or again use an SSO group mapping to automatically add users to the team.

## Example: Embedded Teams Sharing an Account

If multiple teams share a single **Snowflake Account**, we recommend:

1. Create corresponding teams in SELECT and add users directly, or optionally via SSO mappings
2. Create usage groups for each team
3. Grant teams the **Viewer** role on their usage groups

Users will only see their team's usage data and any monitors they create will be scoped to their team, providing clear isolation between teams.