ConductorOne · mindymo · Sep 30, 2026 · Sep 30, 2026
diff --git a/baton/aws.mdx b/baton/aws.mdx
@@ -2,7 +2,7 @@
 title: "Set up an AWS connector"
 description: "C1 provides identity governance for AWS. Integrate your AWS instance with C1 to run user access reviews (UARs) and enable just-in-time (JIT) access requests."
 og:title: "Set up an AWS connector"
 og:description: "C1 provides identity governance for AWS. Integrate your AWS instance with C1 to run user access reviews (UARs) and enable just-in-time (JIT) access requests."
 sidebarTitle: "AWS"
 ---

@@ -46,7 +46,7 @@
 approved, short-lived AWS credential vending. C1 supplies a request-scoped OIDC
 token and age encryption recipient. The connector exchanges the token with AWS
 STS, encrypts the returned credential envelope before it crosses the connector
 boundary, and returns ciphertext plus expiration and assumed-role audit
 metadata.

 The action accepts:
@@ -73,6 +73,34 @@
 topology from its configured issuance mode and apply the corresponding AWS
 limit.
 
+## AWS STS federation token action
+
+The connector also exposes the global `issue_federation_token` action, which
+calls AWS STS `GetFederationToken` to mint temporary credentials for a named
+federated session. The credentials are returned as encrypted secret data; the
+federated user ARN and ID, the session token size, and the session token
+utilization are returned as ordinary fields.
+
+The action accepts:
+
+- `name`: the federated session name, 2 through 32 characters from
+  `[A-Za-z0-9_+=,.@-]`. It is a label for the session, not a lookup of an
+  existing IAM or Identity Center user;
+- `duration_seconds`: optional, 900 through 129,600 (AWS defaults to 43,200);
+- `policy`: an optional inline session policy, as JSON;
+- `policy_arns`: up to 10 managed policy ARNs from the calling IAM user's own
+  account;
+- `tags`: optional session tags, up to 50 key/value pairs; and
+- `minimum_session_token_size`: optional, 0 through 4,096 bytes.
+
+Two constraints are worth calling out. First, `GetFederationToken` must be
+signed with long-term IAM user keys: a connector running on assumed-role or
+other temporary credentials cannot use this action, and the calling identity
+needs `sts:GetFederationToken`. Second, the issued credentials get no
+permissions at all unless you pass `policy` or `policy_arns` — the session's
+access is the intersection of the IAM user's permissions and the policies
+supplied here.
+
 ## Cloud infrastructure access: Organizations and permission sets as scoped bindings
 
 When both **Enable support for AWS Organizations** and **Enable support for AWS IAM Identity Center** are turned on, the connector also models Identity Center permission set assignments as **Cloud Infrastructure Access** bindings, alongside the existing flat per-account entitlement model. This introduces four resource types:
@@ -115,7 +143,7 @@

 - `password_last_used` — the password-based AWS sign-in timestamp.
 - `access_key_last_used` — the most recent use across all of the user's access keys.
 - `access_key_activity_status` — `available` when all required access-key lookups completed, or `unavailable` when AWS denied a lookup or the user or an access key disappeared during the lookup. When unavailable, the connector omits `access_key_last_used` and **Last Login** but preserves `password_last_used`. Throttling, AWS service failures, and other unexpected lookup errors fail the sync rather than setting `unavailable`.

 Populating `access_key_last_used` requires `iam:ListAccessKeys` and `iam:GetAccessKeyLastUsed`; it does not require **Sync secrets**.

@@ -162,7 +190,7 @@

 To sync IAM data (like users, roles, and groups) from multiple AWS child accounts, C1 uses a secure, read-only mechanism called **cross-account access**. When **Sync secrets** is enabled, this also syncs access keys from each child account. This setup works by allowing a central role in your root account to temporarily assume a specific role in each child account. This method ensures that the connector can gather the necessary data without storing credentials or requiring permanent access.

 If you're using this setup, make sure to click **Enable support for AWS Organizations** when setting up the connector in the C1 web UI. You may also enable **Enable support for AWS IAM Identity Center** at the same time. By default, enabling Identity Center alongside Organizations syncs only Identity Center data (users, groups, permission sets, account assignments) and skips cross-account IAM. To also sync IAM users, roles, and groups — plus access keys when **Sync secrets** is enabled — from every child account in this combined mode, additionally enable **Also sync cross-account IAM when Identity Center is enabled**. This flag is off by default so existing Identity Center deployments don't suddenly require child-account `sts:AssumeRole` access.

 **In order to use the connector to gather IAM AWS data, you'll need to configure each sub-account to have a role with a trust policy.** There are two options here:

@@ -884,9 +912,9 @@

 Only the `aws` and `aws-cn` partitions are accepted. A `BATON_ROLE_ARN` in any other partition —
 GovCloud (`aws-us-gov`) or the ISO partitions — is rejected at startup regardless of
 `BATON_USE_ASSUME`. Earlier releases only checked the role ARN's partition when
 `BATON_USE_ASSUME` was set, so a GovCloud role ARN with static credentials would load and then
 construct commercial-partition ARNs; it now fails immediately with the partition named.

 Always set `BATON_GLOBAL_REGION` on the static-key shape. It is the only partition signal the
 connector has there, and leaving it empty means the AWS SDK resolves a region from the ambient
@@ -944,7 +972,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 AWS connector to. AWS 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.

@@ -79,6 +79,24 @@
 to the `vso.auditlog` scope required by incremental sync.
 </Note>
 
+## Team administrators
+
+When **Sync teams** is enabled, each team has an **admin** entitlement that shows everyone Azure DevOps lists as a team administrator. This includes users, groups, and service principals, even if they aren't members of the team. When a group is a team administrator, its members also appear as team administrators in C1.
+
+Administrators who have access only because they are Project Administrators or Project Collection Administrators are not listed, since Azure DevOps doesn't show them as team administrators either.
+
+To read team administrators, the connector needs access to the team's security settings:
+
+- **Client secret:** no extra setup. The service principal is a Project Collection Administrator.
+- **OAuth:** add the `vso.security_manage` and `vso.identity` permissions.
+- **Personal access token:** add the **Security: Manage** and **Identity: Read** scopes.
+
+If the connector can't read the team's security settings, the sync still completes. In that case, only team administrators who are also team members are shown.
+
+<Note>
+Team administrators can't be granted or revoked from C1. Manage them in Azure DevOps. Changes to team administrators are picked up on the next full sync, not by incremental sync.
+</Note>
+
 ## Gather Azure DevOps credentials
 
 Configuring the connector requires you to pass in credentials generated in Azure DevOps. Gather these credentials before you move on.
@@ -143,14 +161,14 @@
  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).
@@ -161,7 +179,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>
@@ -176,14 +194,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**.
@@ -195,10 +213,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>
@@ -215,7 +233,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
@@ -305,7 +323,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**.
@@ -549,7 +567,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/bridge-client.mdx b/baton/bridge-client.mdx
@@ -28,7 +28,7 @@

 The bridge authenticates to C1 via OAuth 2.0 Client Credentials
 with `private_key_jwt`. It periodically refreshes the bearer token and
 pushes the new token into the tunnel's keepalive metadata so the
 C1 relay re-authenticates on every ping. Services advertised
 by the bridge appear on the bridge's detail page in the C1 UI
 once the agent connects.
@@ -253,8 +253,16 @@
 | `C1_BRIDGE_SECRET_CA_PATH`       | `ca_path`       |
 | `C1_BRIDGE_SECRET_CA_PEM`        | `ca_pem`        |
 
 `ca_pem` has no scalar form (`C1_BRIDGE_CA_PEM` doesn't exist) — multi-line PEM data doesn't round-trip cleanly through shell envs, so it lives in YAML or comes from a secret backend.
 
+### macOS certificate trust
+
+On macOS, the bridge uses the macOS certificate trust store by default. If `SSL_CERT_FILE` or `SSL_CERT_DIR` is set, it uses the specified CA bundle or directory instead for connections that rely on system roots, including authentication, gateway, and Vault secret backend connections.
+
+The bridge's `ca_path` and `ca_pem` add certificates to these roots rather than replacing them, so `SSL_CERT_FILE` and `SSL_CERT_DIR` still affect authentication and gateway connections. For the Vault connection, `VAULT_CACERT`, `VAULT_CACERT_BYTES`, or `VAULT_CAPATH` take precedence over system roots.
+
+To use the macOS trust store, unset both variables. If other tools require them, set `GODEBUG=x509sslcertoverrideplatform=0` when running the bridge to use macOS certificate verification while leaving those variables set.
+
 ### Single-service env mode
 
 For deployments that don't want to ship a YAML config at all, a single service mapping can be defined entirely in the environment. When both `C1_BRIDGE_SERVICE_LISTEN_PORT` and `C1_BRIDGE_SERVICE_BACKEND` are set, a single port is constructed from the `C1_BRIDGE_SERVICE_*` vars and **replaces** any `ports:` block loaded from YAML.

diff --git a/baton/cloudflare-zero-trust.mdx b/baton/cloudflare-zero-trust.mdx
@@ -2,7 +2,7 @@
 title: "Set up a Cloudflare Zero Trust connector"
 og:title: "Set up a Cloudflare Zero Trust connector"
 description: "C1 provides identity governance for Cloudflare Zero Trust. Integrate your Cloudflare Zero Trust instance with C1 to run user access reviews (UARs) and enable just-in-time access requests."
 og:description: "C1 provides identity governance for Cloudflare Zero Trust. Integrate your Cloudflare Zero Trust instance with C1 to run user access reviews (UARs) and enable just-in-time access requests."
 sidebarTitle: "Cloudflare Zero Trust"
 ---

@@ -14,6 +14,124 @@
 | Access groups | <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"/> |
 
+## Access group rules
+
+Cloudflare Access groups grant membership using three rule lists with
+different logic:
+
+- **Include** — OR. A user matches the group if at least one rule matches.
+- **Require** — AND. A user must also match every rule in this list.
+- **Exclude** — NOT. A user must not match any rule in this list.
+
+Each list can contain several rule types (email, email domain, everyone,
+country, IP range, IdP group claim, a nested Access group, etc.). This
+connector can evaluate some of them and not others, and rules it cannot
+evaluate are **skipped** rather than treated as non-matching:
+
+| Rule type | Evaluated? | Effect on reported membership |
+| :--- | :--- | :--- |
+| `email`, `email_domain`, `everyone` | Yes | Fully enforced in all three lists. |
+| `group` (nested Access group) | In `Include` only | Reported as an expandable grant — see below. |
+| `ip`, `ip_list`, `geo`, `certificate`, `device_posture`, `auth_method`, `login_method`, `auth_context`, `external_evaluation` | No | None, by design. |
+| `email_list`, IdP group claims (`okta`, `gsuite`, `saml`, ...), service tokens | No | May over- or under-report — see below. |
+
+### Why skipped rules do not narrow membership
+
+Each list combines its rules with a boolean operator, and a skipped rule is
+treated as that operator's neutral element so it cannot change the list's
+answer: satisfied under `Require`'s AND, non-matching under `Include`'s OR
+and `Exclude`'s NOT.
+
+This matters most for `Require`. If a skipped rule were treated as "does not
+match", a single one would make the whole AND fail and the group would report
+**no members at all**. A group with `Include: email` and `Require: geo US`
+really does grant access to that user, and C1 reports it.
+
+<Warning>
+**A group whose `Include` list contains nothing this connector can evaluate
+reports no members at all.** `Include` is an OR, and its neutral element is
+"no match", so a list made up entirely of skipped rules — an IdP-group claim
+on its own, for example, which is a common Access setup — produces an empty
+result.
+
+That direction under-reports rather than over-reports, and an empty group in
+an access review reads as "nobody has access" rather than "this could not be
+determined". The connector cannot tell the difference, and inventing members
+would be worse, so it logs every group in this state at sync time and lists
+the group's rules on its resource profile. Check those groups in Cloudflare
+directly.
+</Warning>
+
+Contextual rules — country, IP range, mTLS certificate, device posture,
+authentication method — are never evaluated, and this is deliberate rather
+than a gap. They constrain *the request*: where it comes from and how it
+authenticated. They do not change *who* the policy grants access to, and
+Cloudflare evaluates them per request, so no connector can resolve them at
+sync time. C1 models who a policy grants access to, not the conditions under
+which that access applies.
+
+<Warning>
+**Rules that name identities this connector cannot read may cause C1 to
+over-report membership.** Nested Access groups referenced from
+`Require`/`Exclude`, email lists, IdP group claims (`okta`, `gsuite`,
+`saml`) and service tokens all name real identities, but in a directory
+this connector does not sync.
+
+Because they are skipped, a user who does not satisfy a `Require` rule — or
+who should be removed by an `Exclude` rule — may still be reported as a
+member of the group. In `Include` the effect runs the other way: a member
+admitted only by such a rule is not reported at all. Every group carrying such a rule is logged at sync
+time, and its rules are listed on the group's profile in C1 under
+`include_rules` / `require_rules` / `exclude_rules`, so you can see exactly
+which conditions were not applied.
+
+For those groups, confirm membership in Cloudflare before relying on C1 for
+an access review.
+</Warning>
+
+A nested Access group referenced in **Include** is represented as an
+expandable grant on the referenced group's own membership — so nested
+group membership (including further nesting) is reflected in C1 without
+this connector re-evaluating every member on every sync.
+
+<Warning>
+**Nested Include membership is not reported when the same group also has
+`Require` or `Exclude` rules that this connector can evaluate.** An
+expandable grant is a union: it pulls in everyone who holds the nested
+group's membership, and the outer group's `Require`/`Exclude` rules cannot
+be applied to the members it pulls in. A member excluded by the outer group
+would otherwise still be reported as a member of it.
+
+Rather than over-report access, the connector omits the nested membership
+for those groups and reports only the members matched directly by the outer
+group's own `email`, `email_domain` and `everyone` rules. Rules that are
+skipped anyway — and a `Require` list consisting only of `everyone` — are
+not treated as restrictions, since they filter nothing. Affected groups are
+logged at sync time.
+</Warning>
+
+### Granting and revoking group membership
+
+C1 adds a member to an Access group by appending an `email` rule to the
+group's `Include` list, and removes one by deleting that rule. Everything
+else about the group — its name and its `Require` and `Exclude` rules — is
+written back unchanged.
+
+Because membership is expressed as rules rather than as a member list, some
+requests cannot be carried out, and the connector refuses them rather than
+reporting a change it did not make:
+
+| Request | Result |
+| :--- | :--- |
+| Grant to someone a `Require` or `Exclude` rule keeps out | **Refused.** The rule would be written but would grant nothing, and C1 would never hold the grant, so the rule would stay in your policy unnoticed. |
+| Grant to someone already admitted by a broad rule (`everyone`, `email_domain`) | **No change.** They already have access, and adding a rule naming them would only leave a redundant one behind. |
+| Revoke from someone whose access comes from a broad rule | **Refused.** That rule governs other members too, so it cannot be edited on one person's behalf. Change it in Cloudflare instead. |
+| Revoke the last `email` rule in a group's `Include` list | **Refused.** Cloudflare rejects a group with an empty `Include` list. Delete or edit the group in Cloudflare instead. |
+| Revoke from someone who is not a member | **No change.** |
+
+Membership that comes from a nested Access group cannot be revoked here
+either: the member belongs to the referenced group, not to this one.
+
 ## Gather Cloudflare Zero Trust credentials
 
 Configuring the connector requires you to pass in credentials generated in Cloudflare Zero Trust. Gather these credentials before you move on.
@@ -68,11 +186,13 @@
          - Account -> Access: Organizations, Identity Providers, and Groups -> Edit
          - Account -> Access: Apps and Policies -> Read
          - Account -> Access: Audit Logs -> Read
+         - Account -> Memberships -> Edit
 
        Otherwise, set:
 
          - Account -> Account Settings -> Read
          - Account -> Access: Organizations, Identity Providers, and Groups -> Read
+         - Account -> Memberships -> Read
          - Account -> Access: Apps and Policies -> Read
          - Account -> Access: Audit Logs -> Read
 
@@ -264,7 +384,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 Cloudflare Zero Trust connector to. Cloudflare Zero Trust 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,47 +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.
 
+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>

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

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

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

  **If you also want to sync and provision Account Groups, add:**
@@ -132,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>
@@ -171,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.
@@ -187,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.

@@ -202,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>
@@ -237,7 +251,7 @@

 ### Step 2: Create Kubernetes configuration files

 Create two Kubernetes manifest files for your Coupa connector deployment:

 #### Secrets configuration

@@ -301,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,30 +17,24 @@
 | 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.
 
-<Warning>
-**Workspace-token (personal access token) authentication is temporarily unavailable.** It is not offered when configuring the connector, and configurations that specify it are rejected at startup. Use OAuth instead.
-
-The connector's PAT implementation is intact and the method is expected to return; it is withheld while a platform-side defect is resolved. The defect is not in this connector: a credential declared as a list of secrets is not treated as secret by the configuration layer, so a workspace token supplied through the UI would be stored unencrypted and displayed in clear text.
-</Warning>
-
 ## 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
@@ -50,22 +44,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.
@@ -78,13 +72,9 @@
 - OAuth client ID
 - OAuth client secret
 
-<Note>
-Personal access token (workspace token) authentication is **temporarily unavailable** and is not offered when configuring the connector, so there is no need to generate one. See [Authentication methods](#authentication-methods) above.
-</Note>
-
 Next, move on to the instructions for your chosen setup method.
 
 ## Configure the Databricks connector

 <Warning>
 To complete this task, you'll need:
@@ -129,9 +119,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**.
@@ -141,12 +131,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.

@@ -191,7 +181,7 @@

 ### Step 2: Create Kubernetes configuration files

 Create two Kubernetes manifest files for your Databricks connector deployment:

 #### Secrets configuration

@@ -208,31 +198,22 @@
  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>
   BATON_DATABRICKS_CLIENT_SECRET: <OAuth client secret>
 
-  # Optional: limit the sync to specific workspaces, by deployment name.
-  # Mutually exclusive with BATON_DATABRICKS_EXCLUDE_WORKSPACES — set one or the other, never both.
-  # BATON_WORKSPACES: <deployment name of workspace-a,deployment name of workspace-b>
-
   # Optional: exclude specific workspaces from the sync
   # (workspace name, deployment name, or numeric ID).
-  # Mutually exclusive with BATON_WORKSPACES — set one or the other, never both.
   BATON_DATABRICKS_EXCLUDE_WORKSPACES: <workspace-a,workspace-b>
 
   # Optional: include if you want C1 to provision access using this connector
   BATON_PROVISIONING: true
 ```
 
-<Warning>
-**`BATON_WORKSPACES` and `BATON_DATABRICKS_EXCLUDE_WORKSPACES` cannot both be set.** They are mutually exclusive, and a config carrying both is rejected at startup before any API call. Choose one.
-</Warning>
-
 <Note>
-OAuth requires a reachable account API. If the account API check fails at startup, the connector fails validation instead of falling back to a workspace-only sync, even when `BATON_WORKSPACES` is set.
+OAuth requires a reachable account API. If the account API check fails at startup, the connector fails validation instead of falling back to a workspace-only sync.
 </Note>
 
 See the connector's README or run `--help` to see all available configuration flags and environment variables.
@@ -274,13 +255,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>

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

@@ -35,7 +35,7 @@
 <Step>
 Create a new project for your organization:
 
-   - **Project Name**: Choose a names, such as "C1 Integration"
+   - **Project Name**: Choose a name, such as "C1 Integration"
    - **Organization/Location**: Choose the appropriate Organization/Location
 
 </Step>
@@ -278,7 +278,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 Google Identity Platform connector to. Google Identity Platform data should be found on the **Entitlements** and **Accounts** tabs.