feat: add docs for teams and scim

public/access-control.md

@@ -34,9 +34,13 @@ User authentication in Phase is designed for seamless and secure access for huma
 
 Programmatic access to secrets in Phase is facilitated by Service Accounts. A Service Account is a special type of account that represents non-human users, such as applications, automation processes, or CI/CD pipelines, that need to interact with Phase programmatically through the API, SDK, or CLI.
 
-[Read more](/access-control/service-accounts) about how service accounts work.  
+[Read more](/access-control/service-accounts) about how service accounts work.
 
+## Teams
 
+Teams let you group members and service accounts together and grant them scoped access to apps and environments. Instead of managing access individually, you assign access at the team level — when someone joins the team, they automatically receive the right encryption keys. Teams support optional role overrides and work with SCIM provisioning for automated group sync.
+
+[Read more](/access-control/teams) about how teams work.
 
 ## Access Control - Key Concepts
 
@@ -78,6 +82,7 @@ Phase's RBAC system allows you to define permissions for Create, Read, Update, a
 | **Members** | Manage user access within the app |
 | **Integrations** | Control setup and management of app integrations |
 | **Encryption Mode** | Manage encryption settings for the app |
+| **Teams** | Manage team-based access within the app |
 
 ## Global Access
 

public/access-control/roles.md

@@ -44,6 +44,8 @@ The organization owner. This role is automatically assigned when a user creates
 | **Roles** | Full access | ✅ | ✅ | ✅ | ✅ |
 | **Integration Credentials** | Full access | ✅ | ✅ | ✅ | ✅ |
 | **Network Access Policies** | Full access | ✅ | ✅ | ✅ | ✅ |
+| **Teams** | Full access | ✅ | ✅ | ✅ | ✅ |
+| **SCIM** | Full access | ✅ | ✅ | ✅ | ✅ |
 | **SSO** | Full access | ✅ | ✅ | ✅ | ✅ |
 
 #### App-level permissions:
@@ -60,6 +62,7 @@ The organization owner. This role is automatically assigned when a user creates
 | **Service Accounts** | Full access | ✅ | ✅ | ✅ | ✅ |
 | **Integrations** | Full access | ✅ | ✅ | ✅ | ✅ |
 | **Encryption Mode** | Full access | ✅ |  | ✅ |  |
+| **Teams** | Full access | ✅ | ✅ | ✅ | ✅ |
 
 ### Admin
 
@@ -80,6 +83,8 @@ Admin users have access to most resources and permissions, and have global acces
 | **Roles** | Full access | ✅ | ✅ | ✅ | ✅ |
 | **Integration Credentials** | Full access | ✅ | ✅ | ✅ | ✅ |
 | **Network Access Policies** | Full access | ✅ | ✅ | ✅ | ✅ |
+| **Teams** | Full access | ✅ | ✅ | ✅ | ✅ |
+| **SCIM** | Full access | ✅ | ✅ | ✅ | ✅ |
 | **SSO** | Full access | ✅ | ✅ | ✅ | ✅ |
 
 #### App-level permissions:
@@ -96,6 +101,7 @@ Admin users have access to most resources and permissions, and have global acces
 | **Service Accounts** | Full access | ✅ | ✅ | ✅ | ✅ |
 | **Integrations** | Full access | ✅ | ✅ | ✅ | ✅ |
 | **Encryption Mode** | Custom access | ✅ |  | ✅ |  |
+| **Teams** | Full access | ✅ | ✅ | ✅ | ✅ |
 
 The `Owner` and `Admin` roles have global access. Learn more about global access [here](/access-control#global-access).
 
@@ -118,6 +124,8 @@ Management users with broad access to environments, secrets, and service account
 | **Roles** | Full access | ✅ | ✅ | ✅ | ✅ |
 | **Integration Credentials** | Full access | ✅ | ✅ | ✅ | ✅ |
 | **Network Access Policies** | Full access | ✅ | ✅ | ✅ | ✅ |
+| **Teams** | Full access | ✅ | ✅ | ✅ | ✅ |
+| **SCIM** | No access | ❌ | ❌ | ❌ | ❌ |
 | **SSO** | No access | ❌ | ❌ | ❌ | ❌ |
 
 #### App-level permissions:
@@ -134,6 +142,7 @@ Management users with broad access to environments, secrets, and service account
 | **Service Accounts** | Full access | ✅ | ✅ | ✅ | ✅ |
 | **Integrations** | Full access | ✅ | ✅ | ✅ | ✅ |
 | **Encryption Mode** | Custom access | ✅ | ❌ | ✅ | ❌ |
+| **Teams** | Full access | ✅ | ✅ | ✅ | ✅ |
 
 ### Service
 
@@ -154,6 +163,8 @@ Default role for Service Accounts, providing programmatic access to secrets with
 | **Roles** | Read access | ✅ | ❌ | ❌ | ❌ |
 | **Integration Credentials** | Read access | ✅ | ❌ | ❌ | ❌ |
 | **Network Access Policies** | Read access | ✅ | ❌ | ❌ | ❌ |
+| **Teams** | No access | ❌ | ❌ | ❌ | ❌ |
+| **SCIM** | No access | ❌ | ❌ | ❌ | ❌ |
 | **SSO** | No access | ❌ | ❌ | ❌ | ❌ |
 
 #### App-level permissions:
@@ -170,6 +181,7 @@ Default role for Service Accounts, providing programmatic access to secrets with
 | **Service Accounts** | Read access | ✅ | ❌ | ❌ | ❌ |
 | **Integrations** | Read access | ✅ | ❌ | ❌ | ❌ |
 | **Encryption Mode** | Read access | ✅ | ❌ | ❌ | ❌ |
+| **Teams** | Read access | ✅ | ❌ | ❌ | ❌ |
 
 ### Developer
 
@@ -190,6 +202,8 @@ Developers have limited permissions at the organization level and must be given
 | **Roles** | Read access | ✅ | ❌ | ❌ | ❌ |
 | **Integration Credentials** | Custom access | ✅ | ✅ | ✅ | ❌ |
 | **Network Access Policies** | Read access | ✅ | ❌ | ❌ | ❌ |
+| **Teams** | Read access | ✅ | ❌ | ❌ | ❌ |
+| **SCIM** | No access | ❌ | ❌ | ❌ | ❌ |
 | **SSO** | No access | ❌ | ❌ | ❌ | ❌ |
 
 #### App-level permissions:
@@ -203,9 +217,10 @@ Developers have limited permissions at the organization level and must be given
 | **Logs** | Read access | ✅ | ❌ | ❌ | ❌ |
 | **Tokens (Legacy)** | Custom access | ✅ | ✅ | ❌ | ❌ |
 | **Members** | Read access | ✅ | ❌ | ❌ | ❌ |
-| **Service Accounts** | Read access | ✅ | ❌ | ❌ | ❌ |
+| **Service Accounts** | Custom access | ❌ | ✅ | ❌ | ❌ |
 | **Integrations** | Full access | ✅ | ✅ | ✅ | ✅ |
 | **Encryption Mode** | Custom access | ✅ |  | ✅ |  |
+| **Teams** | Read access | ✅ | ❌ | ❌ | ❌ |
 
 ## Custom Roles
 
@@ -265,6 +280,12 @@ Some actions require a combination of permissions across multiple resources. Bel
 - To view and delete other users Personal Access Tokens:
     - `MemberPersonalAccessTokens:read`
     - `MemberPersonalAccessTokens:delete`
+- Adding or removing a Team's access to an App:
+    - `Teams:create` or `Teams:delete` (app-level)
+    - `Teams:read` (organisation-level)
+- Managing a Team's environment scope within an App:
+    - `Teams:update` (app-level)
+    - `Teams:read` (organisation-level)
 - To Manage Network Access Policies of a User or Service Account:
     - `Members:read`
     - `Members:update`

public/access-control/service-accounts.md

@@ -9,7 +9,16 @@ Service Accounts provide a secure and controlled method for programmatic access
 
 Service accounts share many of the properties and behavior of human user accounts. Service Accounts follow an Access Policy that can be defined by [Managed Roles](/access-control/roles#managed-roles) or [Custom Roles](/access-control/roles#creating-custom-roles) based on the permissions required. Service accounts are secured with the same security and cryptographic architecture as user accounts, and must be manually provisioned access to Apps and Environments in order to access secrets. 
 
-<DocActions /> 
+<DocActions />
+
+## Org-level vs Team-owned Service Accounts
+
+Service accounts exist in two categories:
+
+- **Org-level** (default): Visible to all organisation members with `ServiceAccounts.read` permission. Created from the organisation-level Service Accounts page. This is the default behavior and works on all plans.
+- **Team-owned**: Created within a [Team](/access-control/teams), visible only to team members and users with global access (Owner/Admin). The service account's lifecycle is tied to the team — if the team is deleted, team-owned SAs are deleted too.
+
+Team-owned service accounts are useful when a team needs dedicated programmatic access for team resources, that is isolated from other teams and users. See [Team-owned service accounts](/access-control/teams#team-owned-service-accounts) for details on creating and managing them.
 
 ## Create a new Service Account
 
@@ -79,12 +88,16 @@ To delete a Service Account, click on the "Delete" button at the bottom of the p
 Each Service Account has its own unique keyring, just like User accounts. KMS modes determine who has access to the service account's keyring and can create and manage tokens for this service account.
 
 #### Client-side KMS
-By default, Service Accounts use **Client-side KMS**. This means only designated users with the required `ServiceAccountTokens` permissions have access to create and manage tokens for this service account. These users are called *Service Account Handlers* and have access the service account's keyring, encrypted with their own keys. 
+By default, org-level Service Accounts use **Client-side KMS**. This means only designated users with the required `ServiceAccountTokens` permissions have access to create and manage tokens for this service account. These users are called *Service Account Handlers* and have access the service account's keyring, encrypted with their own keys.
 
 
 #### Server-side KMS
 You can optionally enable **Server-side KMS** for a Service Account. This grants the Phase backend access to the service account's keyring, effectively making the backend a *Service Account Handler*. Enabling Server-side KMS allows the backend to create and manage tokens on behalf of the Service Account. This is required to use features such as [External Identities](/access-control/external-identities).
 
+<Note>
+  **Team-owned service accounts** always use Server-side KMS. This is enabled automatically when the account is created, so that any team member with the appropriate permissions can generate tokens — without needing to be a designated Service Account Handler. This is important for dynamic team membership, including teams managed via [SCIM provisioning](/access-control/provisioning/scim), where members may join or leave at any time.
+</Note>
+
 #### Manage KMS mode
 
 You can manage the KMS mode for a Service Account by clicking the **Manage** button beside the account KMS indicator at the top of the account page: