ConductorOne · mindymo · Sep 30, 2026 · Sep 30, 2026
diff --git a/baton/argo-cd.mdx b/baton/argo-cd.mdx
@@ -2,33 +2,88 @@
 title: "Set up an Argo CD connector"
 description: "C1 provides identity governance for ArgoCD. Integrate your ArgoCD instance with C1 to run user access reviews (UARs) and enable just-in-time access requests."
 og:title: "Set up an Argo CD connector"
 og:description: "C1 provides identity governance for ArgoCD. Integrate your ArgoCD instance with C1 to run user access reviews (UARs) and enable just-in-time access requests."
 sidebarTitle: "ArgoCD"
 ---
 
 ## Capabilities
 
-| Resource | Sync | Provision |
-| :--- | :--- | :--- |
-| Accounts | <Icon icon="square-check" iconType="solid"  color="#c937ae"/> | <Icon icon="square-check" iconType="solid"  color="#c937ae"/> |
-| Roles | <Icon icon="square-check" iconType="solid"  color="#c937ae"/> | <Icon icon="square-check" iconType="solid"  color="#c937ae"/> |
+| Resource | Sync | Provision | Deprovision |
+| :--- | :--- | :--- | :--- |
+| Accounts | <Icon icon="square-check" iconType="solid"  color="#c937ae"/> | <Icon icon="square-check" iconType="solid"  color="#c937ae"/> | <Icon icon="square-check" iconType="solid"  color="#c937ae"/> |
+| Roles | <Icon icon="square-check" iconType="solid"  color="#c937ae"/> | <Icon icon="square-check" iconType="solid"  color="#c937ae"/> | — |
 
-The ArgoCD connector supports [automatic account provisioning](/product/admin/account-provisioning).
+The ArgoCD connector supports [automatic account provisioning and deprovisioning](/product/admin/account-provisioning).
 
 When a new account is created by C1, the account's password will be sent to a [vault](/product/admin/vaults).
 
-This connector does not support account deprovisioning. You must deprovision accounts directly in ArgoCD.
+The connector also supports credential rotation for local accounts: C1 sets a new random password
+and sends it to a vault. ArgoCD rejects every session and API token issued before a password
+change, so rotation also cuts off the account's existing access.
+
+## Connector actions
+
+Connector actions are custom capabilities that extend C1 automations with app-specific operations.
+
+| Automation step | Actions offered | How the target is selected |
+| :--- | :--- | :--- |
+| Account lifecycle action | `enable_user`, `disable_user` | The step's own target-account selector — either the account in context or a specific account. C1 resolves `user_id` from that account. |
+| [Perform connector action](/product/admin/automations-steps-reference#perform-connector-action) | `revoke_tokens` | Set `user_id` to the ArgoCD account name. |
+
+| Action name | Additional fields | Description |
+| :--- | :--- | :--- |
+| `disable_user` | `user_id` (string, required) | Disables an ArgoCD local account. ArgoCD rejects the account's password and API tokens while it is disabled. Reversible with `enable_user`. |
+| `enable_user` | `user_id` (string, required) | Re-enables a disabled ArgoCD local account, restoring its existing password and API tokens. |
+| `revoke_tokens` | `user_id` (string, required) | Revokes every API token issued to an ArgoCD local account. The account, its password and its enabled state are unchanged. Run it with `disable_user` when a re-enabled account must not get its old tokens back. |
+
+## Account lifecycle
+
+The connector manages ArgoCD **local accounts**. ArgoCD's Account API exposes no delete, disable
+or enable endpoint, so the connector changes accounts through the Kubernetes API, using the
+permissions described in [Gather ArgoCD credentials](#gather-argocd-credentials).
+
+- **Disable / enable** (the `disable_user` and `enable_user` actions) are reversible. The account
+  keeps its password and API tokens, which ArgoCD refuses while the account is disabled and
+  accepts again once it is enabled.
+- **Revoke API tokens** (the `revoke_tokens` action) removes the account's API tokens without
+  touching the account itself.
+- **Rotate password** (credential rotation) sets a new random password and invalidates every
+  session and API token issued before it.
+- **Delete** (account deprovisioning) is permanent. It revokes the account's API tokens, removes
+  its role grants and direct permissions, removes the account, and purges its stored credentials,
+  so an account created later with the same name inherits none of them.
+
+Use `disable_user` to suspend access you may need to restore, and delete to remove the account
+for good.
+
+**Notes:**
+
+- The built-in `admin` account cannot be disabled, enabled, rotated, stripped of its tokens or
+  deleted. The connector also refuses to do any of these, except enable, to the account it
+  authenticates as, since it would lock itself out of ArgoCD. SSO/Dex-managed identities are not
+  local accounts, so there is nothing for the connector to manage for them.
+- Disabling a disabled account, enabling an enabled account, revoking the tokens of an account
+  that has none, or deleting an account that is already gone is reported as success. The actions
+  and rotation fail with a not-found error for an account ArgoCD does not know.
+- Account names may contain only alphanumerics, `-` and `_`. Names containing `.` are rejected,
+  since ArgoCD cannot address them as accounts.
+- Deleting an account rewrites `policy.csv` in `argocd-rbac-cm`, which removes its `#` comment lines.
+- Revoking tokens and rotating another account's password need the `accounts, update` ArgoCD RBAC
+  permission for the connector's account. Deleting accounts also requires the `secrets` Kubernetes
+  permissions described below.
 
 ## Gather ArgoCD credentials
 
 Configuring the connector requires you to pass in credentials generated in ArgoCD. Gather these credentials before you move on.
 
 ### Create a Role with required permissions
 
-The connector needs permissions to read and modify ArgoCD ConfigMaps. Create a Role that grants access to the following ConfigMaps:
+The connector needs permissions to read and modify ArgoCD ConfigMaps, and to read and patch the
+ArgoCD Secret. Create a Role that grants access to the following objects:
 
-- `argocd-rbac-cm`: Contains RBAC policies and role grants (needs read and write access)
-- `argocd-cm`: Contains ArgoCD configuration including user accounts (needs write access for provisioning)
+- `argocd-rbac-cm` ConfigMap: Contains RBAC policies and role grants (needs read and write access)
+- `argocd-cm` ConfigMap: Contains ArgoCD configuration including user accounts (needs write access for provisioning, deprovisioning and the enable/disable actions)
+- `argocd-secret` Secret: Contains local accounts' password hashes and API token records (needs read and write access for account deletion)
 
 ```yaml
 apiVersion: rbac.authorization.k8s.io/v1
@@ -40,14 +95,25 @@
   - apiGroups: [""]
     resources: ["configmaps"]
     verbs: ["get", "list", "patch", "update"]
+  - apiGroups: [""]
+    resources: ["secrets"]
+    resourceNames: ["argocd-secret"]
+    verbs: ["get", "patch"]
 ```
 
 **Required Permissions Explained:**

 - `get`: Read individual ConfigMaps (required to read `argocd-rbac-cm` and `argocd-cm`)
 - `list`: List ConfigMaps in the namespace (required to discover and access the ConfigMaps)
 - `patch`: Partially update ConfigMaps (used to modify RBAC policies and user accounts)
 - `update`: Fully update ConfigMaps (used as an alternative to patch for modifying ConfigMaps)
+- `get`/`patch` on `secrets`: Read and purge a deleted account's stored credentials in `argocd-secret`. Restricted to that one Secret by name, so the connector cannot read the repository and cluster credentials that also live in the `argocd` namespace. Only needed for account deletion; omit the rule entirely if you do not use it.
+
+<Warning>
+  The `argocd-secret` permissions are new. Existing deployments must re-apply this role before
+  account deletion is used. Without them the credential-purge step fails with a `403` after the
+  account has already been deleted, leaving its stored credentials in place.
+</Warning>
 
 Apply with:
 
@@ -239,7 +305,7 @@

 <Steps>
    <Step>
    Create a namespace in which to run C1 connectors (if desired), then apply the secret config and deployment config files.
    </Step>
    <Step>
    Check that the connector data uploaded correctly. In C1, click **Apps**. On the **Managed apps** tab, locate and click the name of the application you added the ArgoCD connector to. ArgoCD data should be found on the **Entitlements** and **Accounts** tabs.

diff --git a/baton/azure-devops.mdx b/baton/azure-devops.mdx
@@ -2,7 +2,7 @@
 title: "Set up a Microsoft Azure DevOps connector"
 og:title: "Set up a Microsoft Azure DevOps connector"
 description: "C1 provides identity governance and just-in-time provisioning for Microsoft Azure DevOps. Integrate your Azure DevOps instance with C1 to run user access reviews (UARs) and enable just-in-time access requests."
 og:description: "C1 provides identity governance and just-in-time provisioning for Microsoft Azure DevOps. Integrate your Azure DevOps instance with C1 to run user access reviews (UARs) and enable just-in-time access requests."
 sidebarTitle: "Microsoft Azure DevOps"
 ---

@@ -26,27 +26,27 @@

 The Azure DevOps connector supports [automatic account provisioning](/product/admin/account-provisioning).

 This connector does not support account deprovisioning. You must deprovision accounts directly in Azure DevOps.

 Some Azure DevOps groups are managed in Microsoft Entra (formerly Azure AD),
 not in Azure DevOps. These groups appear in Azure DevOps and their members are
 visible, but membership changes are made in Entra.

 For Entra-managed groups, the connector accepts add and remove requests and
 reports them as successful without changing membership in Azure DevOps or
 Entra. These groups are assumed to be managed elsewhere — in the Entra admin
 center, through another C1 connector that integrates with Entra, or by another
 process. Reporting requests as successful prevents access reviews and
 just-in-time access requests from stalling on changes the connector does not
 perform.

 To have C1 manage Entra group membership through this connector, enable
 **Entra group membership provisioning** during setup. Requirements:

 - OAuth or client secret authentication. Personal Access Tokens do not support
  changes to Entra group membership.
 - The `GroupMember.ReadWrite.All` Microsoft Graph application permission on the
  Entra app registration, with admin consent in the tenant.

 See [Configure the Azure DevOps connector](#configure-the-azure-devops-connector) below for setup steps.

@@ -146,7 +146,8 @@
     - vso.graph
     - vso.tokenadministration (required to sync personal access tokens)
     - vso.auditlog (required if you enable incremental sync)
-    - vso.identity (optional — required only when **Legacy group identity resolution** is enabled)
+    - vso.identity (optional — required when **Legacy group identity resolution** is enabled, or to sync all team administrators)
+    - vso.security\_manage (optional — required to sync all team administrators)
 
     **For full provisioning (read/write) access:**
     - user\_impersonation (required - Azure DevOps only allows delegated permissions)
@@ -155,20 +156,21 @@
     - vso.memberentitlementmanagement\_write
     - vso.tokenadministration (required to sync personal access tokens)
     - vso.auditlog (required if you enable incremental sync)
-    - vso.identity (optional — required only when **Legacy group identity resolution** is enabled)
+    - vso.identity (optional — required when **Legacy group identity resolution** is enabled, or to sync all team administrators)
+    - vso.security\_manage (optional — required to sync all team administrators)
   </Step>
   <Step>
   Click **Add permissions**.
  </Step>
  <Step>
  **Optional — only required for Entra group membership provisioning.**

  If you want C1 to grant and revoke memberships on Entra-sourced Azure DevOps
  groups (descriptor prefix `aadgp.`), grant this same Entra app the **Microsoft
  Graph** application permission **`GroupMember.ReadWrite.All`** with admin
  consent.

  In the Entra portal, on this app registration:

  1. Click **API permissions** > **Add a permission**.
  2. Choose **Microsoft Graph** (not Azure DevOps).
@@ -179,7 +181,7 @@

  This is the least-privilege Microsoft Graph permission for member-only
  writes; the broader `Group.ReadWrite.All` is not required. Without it,
  Entra group membership provisioning will fail with a clear "missing
  GroupMember.ReadWrite.All" error at the first grant or revoke attempt.
  </Step>
  <Step>
@@ -194,14 +196,14 @@
 <Note>
 This option authenticates as a service principal using the OAuth 2.0 client
 credentials grant — no user interaction required. It supports all sync
 capabilities including PAT sync, license sync, and account provisioning. Entra
 group membership provisioning is also supported when the SP holds the
 `GroupMember.ReadWrite.All` Microsoft Graph permission.
 </Note>

 <Steps>
  <Step>
  In the [Microsoft Entra admin center](https://entra.microsoft.com), navigate to **App registrations** and click **New registration**.
  </Step>
  <Step>
  Give the app a name, select **Accounts in this organizational directory only**, leave the redirect URI blank, and click **Register**.
@@ -213,10 +215,10 @@
  Click **Certificates & secrets** > **New client secret**. Set a description and expiry, then click **Add**. Copy and save the secret **Value** immediately — it is not shown again.
  </Step>
  <Step>
  **No Azure DevOps API permission is required.** Azure DevOps does not expose application permissions in Entra — for the Azure DevOps API the **Application permissions** option is disabled, and the service principal does not need one. The connector uses the OAuth 2.0 client credentials grant against the Azure DevOps resource; the service principal is authorized by being added to your organization in the steps below.
  </Step>
  <Step>
  **Optional — only required for Entra group membership provisioning.**

  Click **API permissions** > **Add a permission** > **Microsoft Graph** > **Application permissions** > select **`GroupMember.ReadWrite.All`** > click **Add permissions**. Then click **Grant admin consent for &lt;tenant&gt;** and confirm — the status column must show a green checkmark.
  </Step>
@@ -233,7 +235,7 @@
 ### Option 3: Create a personal access token

 <Note>
 Personal Access Token authentication does **not** support Entra group
 membership provisioning. With PAT auth, grant and revoke requests against
 Entra-sourced groups (descriptor prefix `aadgp.`) are silent no-ops — the
 connector accepts the request and returns success without making any API
@@ -267,6 +269,9 @@
     To enable incremental sync (optional):
     - **Audit Log: Read** - Required if you want to enable the incremental sync feature, which syncs only changes since the last sync (`vso.auditlog`)
     - **Identity: Read** - Required only if you also enable **Legacy group identity resolution** to resolve legacy group descriptors via the Identities API (`vso.identity`). This setting defaults to off and is separate from Graph: Read.
+    To sync all team administrators, including those who aren't team members (optional):
+    - **Security: Manage** - Required to read the team's administrators (`vso.security_manage`)
+    - **Identity: Read** - Required to identify each team administrator (`vso.identity`)
   </Step>
   <Step>
   Click **Create**.
@@ -323,7 +328,7 @@
    2. **Optional.** Check the boxes if you want to **Sync teams** or **Sync organizations**.
    3. **Optional.** Check **Enable incremental sync** to allow the connector to read audit logs and capture updates between full syncs. Requires the **Audit Log: Read** permission.
    4. **Optional.** Check **Enable legacy group identity resolution** to process legacy group audit events. This setting defaults to off and requires `vso.identity`.
    5. **Optional.** Check **Enable Entra group membership provisioning** to grant and revoke memberships on Entra-sourced groups via Microsoft Graph. Requires the `GroupMember.ReadWrite.All` Microsoft Graph application permission with admin consent. Per Microsoft, changes may take up to 1 hour to appear in the Azure DevOps Members view.
    6. **Optional.** Check **Use project RBAC roles** to enable the Cloud Infrastructure Access model for project access. Project-scoped groups are also synced as structured Project Role Assignment resources, with role and project context visible on each entitlement. See [Project RBAC](#project-rbac) for details.
    7. Click **Save**.
    8. Click **Login with OAuth**.
@@ -567,7 +572,7 @@

 <Steps>
  <Step>
  Create a namespace in which to run C1 connectors (if desired), then apply the secret config and deployment config files.
  </Step>
  <Step>
  Check that the connector data uploaded correctly. In C1, click **Apps**. On the **Managed apps** tab, locate and click the name of the application you added the Azure DevOps connector to. Azure DevOps data should be found on the **Entitlements** and **Accounts** tabs.

diff --git a/baton/azure.mdx b/baton/azure.mdx
@@ -2,7 +2,7 @@
 title: "Set up a Microsoft Azure connector"
 description: "C1 provides identity governance and just-in-time provisioning for Azure. Integrate your Azure instance with C1 to run user access reviews (UARs), enable just-in-time access requests, and automatically provision and deprovision access."
 og:title: "Set up a Microsoft Azure connector"
 og:description: "C1 provides identity governance and just-in-time provisioning for Azure. Integrate your Azure instance with C1 to run user access reviews (UARs), enable just-in-time access requests, and automatically provision and deprovision access."
 sidebarTitle: "Microsoft Azure"
 ---

@@ -15,14 +15,15 @@
 | Accounts | <Icon icon="circle-info" /> |  |
 | Groups | <Icon icon="circle-info" /> |  |
 | Managed identities | <Icon icon="circle-info" /> |  |
+| Enterprise applications | <Icon icon="circle-info" /> |  |
 | Azure roles | <Icon icon="square-check" iconType="solid"  color="#c937ae"/> | <Icon icon="square-check" iconType="solid"  color="#c937ae"/> |
 | Tenant root | <Icon icon="square-check" iconType="solid"  color="#c937ae"/> |  |
 | Management groups | <Icon icon="square-check" iconType="solid"  color="#c937ae"/> |  |
 | Resource groups | <Icon icon="square-check" iconType="solid"  color="#c937ae"/> |  |
 | Subscriptions | <Icon icon="square-check" iconType="solid"  color="#c937ae"/> |  |
 | Azure resources (opt-in) | <Icon icon="square-check" iconType="solid"  color="#c937ae"/> |  |
 
-<Icon icon="circle-info" /> This connector pulls account, group, and managed identity information from the Entra ID connector. You'll configure this relationship when setting up the connector.
+<Icon icon="circle-info" /> This connector pulls account, group, managed identity, and enterprise application information from the Entra ID connector. You'll configure this relationship when setting up the connector.
 
 ## Gather Azure credentials
 
@@ -32,17 +33,17 @@
 A user with the **Global Administrator** permission in Azure must perform this task.
 </Warning>

 ### Create a new Entra application

 <Steps>
 <Step>
 In the Entra admin center, navigate to **App registrations**.
 </Step>
 <Step>
 Click **\+ New registration**.
 </Step>
 <Step>
 Give the application a name, such as "C1", and select the supported account type relevant to your Entra installation. You do not need to set a redirect URL.
 </Step>
 <Step>
 Click **Register**.
@@ -132,7 +133,7 @@
 ```
 </Step>
 <Step>
 Assign the **User Access Administrator** role to your app at the tenant root scope. Replace `<app-object-id>` with the **Object ID** of your Entra app registration (found in Entra ID → App registrations → your app → Overview):

 ```sh
 az role assignment create \
@@ -145,7 +146,7 @@
 <Step>
 Revoke the Global Administrator's temporary elevated access using one of the following methods:

   **Option A — Azure Portal:** Navigate to **Microsoft Entra ID** → **Properties**, set **Access management for Azure resources** back to **No**, and click **Save**.

   **Option B — Azure CLI:**
   ```sh
@@ -168,10 +169,68 @@
 
 ### Optional configuration
 
-Two additional settings are available in the connector's configuration form:
+Three additional settings are available in the connector's configuration form:
 
 - **Azure cloud** — the Azure cloud environment to connect to: `public` (default), `usgovernment`, or `china`. This is the only way to point the connector at the US Government or China clouds instead of the public Azure cloud.
 - **Skip roles with no assignments** — when enabled, only Azure roles with at least one active assignment are synced, instead of every role definition in scope.
+- **Sync sub-resources** — which kinds of nested sub-resource to sync. Leave empty to sync none. Sub-resources are not a separate resource type: each one is synced as an **Azure resource**, nested under the Azure resource that owns it.
+
+<Note>
+**Sync sub-resources only has an effect if the Azure resources resource type is enabled.**
+
+Sub-resources are synced as children of the Azure resources that own them — a blob container is
+synced under its storage account. If Azure resources are not being synced, there are no parents
+to sync them under, and enabling this setting does nothing.
+</Note>
+
+#### Supported sub-resource types
+
+Each value below is a scope Azure documents as directly role-assignable. Everything listed here
+syncs as an Azure resource — the values select which kinds are included, not which resource types
+exist. Select only the ones you need: **each selected value costs one extra API call per parent
+resource, on every sync.**
+
+| Value | Syncs, as an Azure resource | Nested under |
+| :--- | :--- | :--- |
+| `blob_containers` | Blob containers | Storage accounts |
+| `storage_queues` | Storage queues | Storage accounts |
+| `storage_tables` | Storage tables | Storage accounts |
+| `service_bus_queues` | Service Bus queues | Service Bus namespaces |
+| `service_bus_topics` | Service Bus topics | Service Bus namespaces |
+| `event_hubs` | Event hubs | Event Hubs namespaces |
+| `subnets` | Subnets | Virtual networks |
+
+Not currently supported: Key Vault secrets, keys and certificates (listing them requires a Key
+Vault data-plane connection, which is separate from the Azure Resource Manager access this
+connector uses), Azure Files shares, Service Bus topic subscriptions, and Event Hubs consumer
+groups.
+
+#### Why sync sub-resources
+
+Azure allows a role to be assigned directly at a sub-resource scope. A common example is granting
+`Storage Blob Data Contributor` on a single blob container rather than on the whole storage
+account:
+
+```
+/subscriptions/{id}/resourceGroups/{rg}/providers/Microsoft.Storage/storageAccounts/{account}/blobServices/default/containers/{container}
+```
+
+Assignments made at those scopes are only visible in C1 if the sub-resource itself is synced.
+With this setting disabled, access granted on an individual container does not appear anywhere,
+even though the storage account above it syncs normally.
+
+The trade-off is API calls: each selected type costs one additional request per parent resource
+per sync — selecting all three storage types means three extra calls for every storage account in
+the tenant. That is why nothing is selected by default, and why the types are chosen individually
+rather than with a single on/off switch.
+
+<Note>
+If a resource cannot be listed because it does not offer that sub-resource at all — a disabled
+storage account, or a Premium account that has no queue or table service — the connector skips it
+and continues syncing everything else. A permissions error is different: if the connector is not
+allowed to list a resource's children, the sync fails, because silently syncing less access than
+exists would be misleading.
+</Note>
 
 ## Configure the Azure connector
 
@@ -226,9 +285,10 @@
 <Step>
 Finally, tell the connector where to find the identities that will be used for this app in C1.
    1. In the **Shared identity source** area of the page, click **Edit**.
    2. Select your Entra connector.
-   3. **Optional.** Limit the identities pulled from the connector you selected to only those with a certain entitlement by setting the entitlement.
-   4. Click **Save**.
+   3. Under **Only import identities of type**, select **Users**, **Groups**, and **Apps**. Azure reports both managed identities and enterprise applications as service principals, so role assignments held by an enterprise application only resolve when **Apps** is selected.
+   4. **Optional.** Limit the identities pulled from the connector you selected to only those with a certain entitlement by setting the entitlement.
+   5. Click **Save**.
 </Step>
 <Step>
 The connector's label changes to **Syncing**, followed by **Connected**. You can view the logs to ensure that information is syncing.
@@ -350,7 +410,7 @@

 <Steps>
 <Step>
 Create a namespace in which to run C1 connectors (if desired), then apply the secret config and deployment config files.
 </Step>
 <Step>
 Check that the connector data uploaded correctly. In C1, click **Apps**. On the **Managed apps** tab, locate and click the name of the application you added the Azure connector to. Azure data should be found on the **Entitlements** and **Accounts** tabs.

diff --git a/baton/coupa.mdx b/baton/coupa.mdx
@@ -1,13 +1,13 @@
 ---
 title: "Set up a Coupa connector"
 og:title: "Set up a Coupa connector"
 description: "C1 provides identity governance for Coupa. Integrate your Coupa instance with C1 to run user access reviews (UARs) and enable just-in-time access requests."
 og:description: "C1 provides identity governance for Coupa. Integrate your Coupa instance with C1 to run user access reviews (UARs) and enable just-in-time access requests."
 sidebarTitle: "Coupa"
 ---

 <Tip>
 **This is an updated and improved version of the Coupa connector!** If you're setting up Coupa with C1 for the first time, you're in the right place.
 </Tip>

 ## Capabilities
@@ -21,61 +21,61 @@
 | Roles | <Icon icon="square-check" iconType="solid"  color="#c937ae"/> | <Icon icon="square-check" iconType="solid"  color="#c937ae"/> |
 | Licenses | <Icon icon="square-check" iconType="solid"  color="#c937ae"/> | <Icon icon="square-check" iconType="solid"  color="#c937ae"/> |

 ¹ Account Groups sync is opt-in. To enable it, select **Account Groups** in the resource types to sync when configuring the connector in C1, and ensure the `core.accounting.read` OAuth scope is added to your Coupa OAuth client.

 The **Licenses** resource surfaces each user's Coupa license assignments — such as Analytics, Purchasing, Sourcing, CLM Advanced, Navi AI Agent, and Intake — as license profiles, so they can be reviewed and provisioned through C1 License Management.

 ### Account provisioning

 C1 can create Coupa user accounts. When you configure account provisioning for the app, map these profile fields:

 | Field | Description |
 |-------|-------------|
 | First name | First name of the person who will own the Coupa user. |
 | Last name | Last name of the person who will own the Coupa user. |
 | Email | Email address of the Coupa user. Defaults to the C1 user's primary email. |
 | Login | Login for the Coupa user. Defaults to the C1 user's username. |
 | SSO identifier | Single sign-on identifier for the Coupa user. |
 | Employee number | Employee number for the Coupa user. |
 | Manager login | Login of the user's manager in Coupa. |
 | Purchasing user | Assign a Purchasing license when the account is created. |
 | Invoicing user | Assign an Invoicing license when the account is created. |
 | Sourcing user | Assign a Sourcing license when the account is created. |
 | Account security type | Numeric Coupa account security type. |
 | Authentication method | `coupa_credentials`, `ldap`, or `saml`; values are case-sensitive. |
 | Default locale | Default locale, such as `en` or `en-GB`. |
 | Default account type | Name of the user's default Coupa account type. |
 | Default currency | ISO currency code, such as `USD`. |
 | Custom fields | Map of instance-specific Coupa user field names to values. |
 
 Every field is optional to C1. Map **First name** and **Last name** regardless — Coupa has no other source for a new user's name.
 
-Accounts are created active. Coupa authenticates through SSO, so no password is set.
+Accounts are created active. The connector does not set a password.
 
 Custom fields are sent in Coupa's `custom-fields` namespace. License assignments can also be managed after account creation through C1 License Management.
 
 ### Connector actions

 Connector actions are custom capabilities that extend C1 automations with app-specific operations. You can use connector actions in the [Perform connector action](/product/admin/automations-steps-reference#perform-connector-action) automation step.

 | Action name | Additional fields | Description |
 |-------------|-------------------|-------------|
 | enable_user | `user_id` (string, required) — the Coupa user's numeric ID, the `id` field on `/api/users` | Enables a disabled user account in Coupa, allowing them to access the system |
 | disable_user | `user_id` (string, required) — the Coupa user's numeric ID, the `id` field on `/api/users` | Disables an active user account in Coupa, preventing them from accessing the system |

 ## Gather Coupa credentials

 Configuring the connector requires you to pass in credentials generated in Coupa. Gather these credentials before you move on.

 <Warning>
 A user with **Admin** access in Coupa must perform this task.
 </Warning>

 ### Look up your Coupa domain

 <Steps>
  <Step>
  Log into your Coupa control panel and copy the URL from your browser.
  </Step>
 </Steps>

@@ -83,7 +83,7 @@

 <Steps>
  <Step>
  In the Coupa control panel, click **Setup**.
  </Step>
  <Step>
  Search for "OAuth" and click **OAuth2/OpenID Connect Clients**.
@@ -105,7 +105,7 @@
    - core.user_group.read
    - core.user.read
    - login
    - openid
    - profile

  **If you also want to sync Account Groups, add:**
@@ -119,7 +119,7 @@
    - core.user.read
    - core.user.write
    - login
    - openid
    - profile

  **If you also want to sync and provision Account Groups, add:**
@@ -146,13 +146,13 @@

 **Done.** Next, move on to the connector configuration instructions.

 ## Configure the Coupa connector

 <Warning>
 To complete this task, you'll need:

 - The **Connector Administrator** or **Super Administrator** role in C1
 - Access to the set of Coupa credentials generated by following the instructions above
 </Warning>

 <Tabs>
@@ -185,7 +185,7 @@
  Find the **Settings** area of the page and click **Edit**.
  </Step>
  <Step>
  Enter your Coupa domain in the **Domain** field.
  </Step>
  <Step>
  Paste the client ID into the **Client ID** field.
@@ -201,12 +201,12 @@
  </Step>
 </Steps>

 **Done.** Your Coupa connector is now pulling access data into C1.

 </Tab>
 <Tab title="Self-hosted">

 **Follow these instructions to use the Coupa connector, hosted and run in your own environment.**

 When running in service mode on Kubernetes, a self-hosted connector maintains an ongoing connection with C1, automatically syncing and uploading data at regular intervals. This data is immediately available in the C1 UI for access reviews and access requests.

@@ -216,7 +216,7 @@

 * [GitHub repository](https://github.com/conductorone/baton-coupa): Access the source code, report issues, or contribute to the project.

 ### Step 1: Set up a new Coupa connector

 <Steps>
  <Step>
@@ -251,7 +251,7 @@

 ### Step 2: Create Kubernetes configuration files

 Create two Kubernetes manifest files for your Coupa connector deployment:

 #### Secrets configuration

@@ -315,14 +315,14 @@

 <Steps>
  <Step>
  Create a namespace in which to run C1 connectors (if desired), then apply the secret config and deployment config files.
  </Step>
  <Step>
  Check that the connector data uploaded correctly. In C1, click **Apps**. On the **Managed apps** tab, locate and click the name of the application you added the Coupa connector to. Coupa data should be found on the **Entitlements** and **Accounts** tabs.
  </Step>
 </Steps>

 **Done.** Your Coupa connector is now pulling access data into C1.

 </Tab>
 </Tabs>

diff --git a/baton/databricks.mdx b/baton/databricks.mdx
@@ -1,8 +1,8 @@
 ---
 title: "Set up a Databricks connector"
 og:title: "Set up a Databricks connector"
 description: "C1 provides identity governance and just-in-time provisioning for Databricks. Integrate your Databricks instance with C1 to run user access reviews (UARs) and enable just-in-time access requests."
 og:description: "C1 provides identity governance and just-in-time provisioning for Databricks. Integrate your Databricks instance with C1 to run user access reviews (UARs) and enable just-in-time access requests."
 sidebarTitle: "Databricks"
 ---

@@ -17,24 +17,20 @@
 | Users | <Icon icon="square-check" iconType="solid"  color="#c937ae"/> | <Icon icon="square-check" iconType="solid"  color="#c937ae"/> |
 | Workspaces | <Icon icon="square-check" iconType="solid"  color="#c937ae"/> | <Icon icon="square-check" iconType="solid"  color="#c937ae"/> |

 The Databricks connector supports [automatic account provisioning and deprovisioning](/product/admin/account-provisioning).
 
 [This connector syncs non-human identities](/product/admin/nhi) and displays them on the **Identities overview** dashboard.
 
-<Note>
-Provisioning **account groups** requires OAuth authentication. It is not available when authenticating with a workspace token, because the Databricks API does not allow provisioning account groups from a workspace token. Workspace-scoped groups can still be provisioned with a workspace token.
-</Note>
-
 ## Authentication methods
 
-The connector authenticates with **OAuth** — an account-level service principal's client ID and secret. This is the only method currently offered.
+The connector authenticates with **OAuth** — an account-level service principal's client ID and secret. This is the only authentication method the connector supports.
 
 ## Gather Databricks credentials
 
 Configuring the connector requires you to pass in credentials generated in Databricks. Gather these credentials before you move on.

 <Warning>
 A user with the **Account admin** role in each Databricks workspace you want to sync must perform this task.
 </Warning>

 ### Look up your Databricks account ID
@@ -44,22 +40,22 @@
  Ensure that your Databricks user account has the **Account admin** role and is assigned to each Databricks workspace you want to sync to C1.
  </Step>
  <Step>
  In the Databricks account console, open the menu that appears next to your username in the upper right corner.
  </Step>
  <Step>
  Carefully and copy and save account ID.
  </Step>
 </Steps>

 ### Generate Databricks credentials

 The Databricks connector authenticates with OAuth:

 - **OAuth** (syncs info from all Databricks workspaces)

  <Steps>
    <Step>
    Follow the [Databricks OAuth authentication documentation](https://docs.databricks.com/en/dev-tools/auth/oauth-m2m.html) to create a service principal and create an OAuth secret.
    </Step>
    <Step>
    Carefully copy and save the OAuth client ID and secret.
@@ -74,7 +70,7 @@

 Next, move on to the instructions for your chosen setup method.

 ## Configure the Databricks connector

 <Warning>
 To complete this task, you'll need:
@@ -119,9 +115,9 @@
  Enter your OAuth client ID and client secret into the **OAuth2 Client ID** and **OAuth2 Client Secret** fields.
  </Step>
  <Step>
  **Google Cloud Platform and Azure Databricks customers only:** Enter your Databricks account hostname and hostname in the relevant fields.
    - For more on how to look up these values for GCP, see the GCP Databricks [REST API reference](https://docs.databricks.com/api/gcp/account/introduction) and [identifiers for workspace objects](https://docs.gcp.databricks.com/en/workspace/workspace-details.html) documentation.
    - For more on how to look up these values for Azure Databricks, see the the Azure Databricks [REST API reference](https://docs.databricks.com/api/azure/account/introduction) and [identifiers for workspace objects](https://learn.microsoft.com/en-us/azure/databricks/workspace/workspace-details) documentation.
  </Step>
  <Step>
  Click **Save**.
@@ -131,12 +127,12 @@
  </Step>
 </Steps>

 **Done.** Your Databricks connector is now pulling access data into C1.

 </Tab>
 <Tab title="Self-hosted">

 **Follow these instructions to use the Databricks connector, hosted and run in your own environment.**

 When running in service mode on Kubernetes, a self-hosted connector maintains an ongoing connection with C1, automatically syncing and uploading data at regular intervals. This data is immediately available in the C1 UI for access reviews and access requests.

@@ -181,7 +177,7 @@

 ### Step 2: Create Kubernetes configuration files

 Create two Kubernetes manifest files for your Databricks connector deployment:

 #### Secrets configuration

@@ -198,7 +194,7 @@
  BATON_CLIENT_SECRET: <C1 client secret>

  # Databricks account ID (required for both credential options below)
  BATON_ACCOUNT_ID: <Databricks account ID>

  # Databricks credentials: OAuth
  BATON_DATABRICKS_CLIENT_ID: <OAuth client ID>
@@ -255,13 +251,13 @@

 <Steps>
  <Step>
  Create a namespace in which to run C1 connectors (if desired), then apply the secret config and deployment config files.
  </Step>
  <Step>
  Check that the connector data uploaded correctly. In C1, click **Apps**. On the **Managed apps** tab, locate and click the name of the application you added the Databricks connector to. Databricks data should be found on the **Entitlements** and **Accounts** tabs.
  </Step>
 </Steps>

 **Done.** Your Databricks connector is now pulling access data into C1.

 </Tab>