Teams overview

A team in VaultTerm is a named grouping of users inside an organization — a way to scope who can reach which vaults and who approves access to them. A team is not the same thing as the users in it: people exist at the organization level, and a team simply collects some of them under a shared set of roles and shared vaults. The same person can belong to several teams.

How teams relate to organizations

Teams live entirely within one organization, which is the tenant and the isolation boundary. Because of that, team membership hard-requires organization membership: you cannot add someone to a team unless they already belong to that team’s org. There is no path to pull a user from another tenant into a team — the org boundary is enforced first, and the team is a grouping underneath it.

Teams count toward your plan’s seats. A user who is a member of one or more teams is a billable seat; removing someone from the org removes them from every team in a single step.

Team roles

Every membership carries one of four roles. These are the same roles used for vault sharing, so the mental model stays consistent across the product — see Roles and permissions for the full permission matrix.

Role	What it can do
OWNER	Full control of the team, including managing members and managing the team’s shared vaults
ADMIN	Invite members and manage their roles
EDITOR	Read and write shared resources, and invite members
VIEWER	Read-only access

Roles are least-privilege by design: most members hold VIEWER or EDITOR, and the elevated powers (manage_members, manage_vault) sit only with ADMIN and OWNER.

What teams do

• Share vaults with granular roles. A team can be granted access to one or more vaults, and the role assigned per vault decides whether members can read, write, delete, or manage that vault. A team that only needs to read production credentials is granted VIEWER; a team that maintains them is granted EDITOR or higher.
• Run JIT approval chains. Teams are the approval unit for just-in-time access. When a member requests time-boxed access to a resource, the team’s OWNER and ADMIN members are the approvers. JIT can only grant the non-privileged VIEWER and EDITOR roles, so an approved grant can never confer the very manage_members power used to approve grants.
• Keep standing access small. Because routine access can be requested just-in-time and expires on its own, teams hold only the permanent access they genuinely need day to day.

Where to go next

• Understand the permission gates behind each role in Roles and permissions.
• See how time-boxed access is requested and approved in Just-in-time access.
• Learn how the org boundary isolates tenants in Organizations and tenancy.