Teams

A team is a group of members with shared permissions and shared resource ownership. Teams are how you scale access control past the first few people in an org: instead of granting permissions per-member, you put people on the right teams and let team-level roles do the work.

What teams are for

Teams play three roles in LakeSail:

1. A bag of people. Members are added to teams; the team becomes the unit of "who is on this project."
2. A unit of permission. Each member gets a team role per team they're on, granting them specific permissions for resources owned by that team.
3. A unit of resource ownership. Jobs, queries, catalogs, and other resources have a team field. Members of the owning team (and members of any teams the resource is shared with) can use the resource according to their roles.

A member can belong to any number of teams. A resource has one owning team but can be shared with additional teams.

Why teams instead of just roles

Two benefits:

• Scoping. Alice is admin of data-eng but viewer of analytics. Org-wide roles can't express that; team roles can.
• Audit and review. "Who has write access to the prod ETL jobs?" is the membership of data-eng, plus anyone with an org-wide admin role. That's a much shorter list to review than "scan every member's permissions."

For a 2-person org you can ignore teams. The moment a third person needs access to some but not all resources, teams pay back the setup cost.

Create a team

1. Open Settings → Teams and click Create team.
2. Give it a Name (e.g. data-eng, analytics-readonly) and a description.
3. Save.

The creator is automatically a member of the team with the highest team role.

Add and remove members

1. Open the team detail page.
2. Click into Members and use Add member.
3. Pick the member and pick their team role for this team. The same person can hold different team roles on different teams — admin on one, viewer on another.
4. To remove, click the member's row and select Remove from team. They keep their org membership and any other team memberships; only this team's permissions go away.

Auto-membership via org roles

Some organization roles set allTeams: true. Members holding those roles are automatically added to every team in the organization, with no manual step. This is how an "Org Admin" role guarantees admin access to every team's resources without repeating the assignment.

You can see whether a role auto-joins teams from Settings → Roles. See Roles & permissions for which roles do this.

Share a resource with a team

Most resources (jobs, queries, catalogs) carry a primary teamId and can be shared with additional teams.

• Open the resource and look for Teams or Sharing.
• Add a team to grant its members access (the level of access depends on their team roles).
• Remove a team to revoke access for everyone on it.

The owning team has the strongest tie — it determines who can edit, delete, and re-share. Shared teams typically get read or run access without ownership rights.

Transfer ownership

To move a resource from one team to another:

1. Open the resource (job, query, etc.).
2. Edit the Team field to the new owner.
3. Save.

The previous team loses write access immediately. If you also want to revoke read access, remove that team from the resource's shared list.

Delete a team

1. Open the team and click Delete.
2. Confirm.

Deleting a team removes its membership relationships and disconnects it from any resources it owned. Resources owned solely by the team are left without an owner — only org admins can edit them until you reassign. Plan ownership transfers before deleting.

Common team patterns

• Functional teams — data-eng, analytics, ml, platform. Ownership splits along function lines; cross-function access via sharing.
• Project teams — project-launchpad, project-redesign. Time-bounded; tear them down when the project ends.
• Environment teams — prod-writers, prod-readers. A small set of high-privilege members on prod-writers; a wider audience on prod-readers. Resources in production share with both, granting different access levels.
• A single all-hands team — for very small orgs, one team that everyone joins. Skip the structure until it pays for itself.

API reference

• Teams — CreateTeam, team membership, and UpdateTeamMemberRoles for assigning team roles.