Fix stale UI labels across admin and how-to docs

product/admin/applications.mdx

@@ -15,7 +15,7 @@
 
 - **Managed apps:** These are the apps you've set up in C1 so it can provide visibility, governance, and automation. You're actively managing these apps with C1.  
 
 - **Unmanaged apps:** When you add a connector for an app that is an identity provider (IdP), SSO, or federation provider, the connector discovers the child apps inside of it. These apps are listed as unmanaged. You can move these apps to the **Managed** state (more on that below) or leave them as-is.
 
 - **Shadow apps:** These are apps that have been discovered in your environment but are likely not sanctioned for use by your organization's corporate IT. [Learn more about shadow apps](/product/admin/shadow-apps).
 
@@ -27,7 +27,7 @@
 
 Use **Configure columns** in the table header to adjust which columns are visible — toggle columns on or off and drag to reorder. Your layout is saved automatically.
 
-To export apps data to CSV, click **Generate CSV** above the **Apps** table. The **Download to CSV** drawer opens where you can choose which columns to include before generating the file.
+To export apps data to CSV, click **Generate CSV** above the **Apps** table. The **Download as CSV** drawer opens where you can choose which columns to include before generating the file.
 
 ## Create a new application 
 
@@ -47,9 +47,9 @@
 
    * **Connector** to sync data automatically through a direct integration with the tool or service. 
 
    * **File import** to upload access data from a file or datasource. Learn more about [formatting files for upload](/baton/file-connectors).
 
       Also select this option if you want to create a custom app that provisions access using webhooks or helpdesk tickets. 
 
    * **Single-sign-on provider** to pull data about the app via your single-sign-on provider's connector. 
 </Step>
@@ -62,11 +62,11 @@
 
   * For a **File import** app, set the new app's name and provide a description. You'll be prompted to import the data on the next screen. 
 
   * For a **Single-sign-on** app, select the application from the list of currently unmanaged apps. Optionally, select a connector to add to this app.  
 
     Adding a connector to a single-sign-on app means that the application will contain records of both what the single-sign-on provider knows about the app (activity and accounts), and the resource and entitlement data pulled from the software itself by the connector. 
 
     For example, if your organization signs into BizApp via your SSO provider, you'd select the unmanaged BizApp application, then add the BizApp connector you set up to pull access data directly from the software into C1. (You can also add a connector to a single-sign-on app later, if it's not set up quite yet.) 
 
 </Step>
 <Step>
@@ -83,15 +83,15 @@
 **Done.** From here, you can configure the new app, add connectors or upload data, view resources, entitlements, and accounts, run reports, and more. 
 
 
 ## Move an unmanaged app to managed
 
 When you add a connector for an app that is an identity provider (IdP), SSO, or federation provider, the connector discovers the apps that are inside of it. These apps are added to the **Unmanaged** app list. 
 
 <Warning>
 A user with the **Super Administrator** role in C1 must complete this task.
 </Warning>
 
 If you want to bring an unmanaged app under C1 management so you can start enforcing access controls on it: 
 
 <Steps>
 <Step>
@@ -109,7 +109,7 @@
    [Learn more about app owners.](#manage-app-owners)
 </Step>
 <Step>
 Click **Manage**. The unmanaged app becomes a new managed app. 
 </Step>
 </Steps>
 
@@ -196,6 +196,6 @@
 
 ### Delete applications with great caution! 
 
 If you delete an IdP, federation, or SSO provider application from C1, all of the applications that have been discovered within it, both those that are unmanaged and those you've moved to managed and added connectors to, will also be deleted. You'll have to manually recreate these apps and re-add connectors to them to continue managing them with C1. 
 
 

product/admin/attributes.mdx

@@ -23,7 +23,7 @@
 
 **Standard** user attributes are pre-defined by C1 (the list of these is shown below). This data is shown in the **User details** section of the user's page. 
 
 Standard attribute data is displayed on each user's details page and on the summary tooltip that's shown when you hover over a user's name. It's useful for giving reviewers, admins, and managers a complete picture of who a user is when making decisions about access. 
 
 **Custom** user attributes are defined by your organization. This data is shown in the **Profile attributes** section of the user's page. 
 
@@ -54,7 +54,7 @@
    - Manager Email* 
    - Directory Status (the employee's status in the IdP, such as active, suspended, or deleted)
    - Employment Type (such as full-time employee, contractor, intern)
    - Employment Status (the employees's status in the HR system, such as active, suspended, or deleted)
    - Department
    - Job Title
    - Additional Username*
@@ -80,7 +80,7 @@
 
          **Don't see the attribute you need?** Check to make sure that the application you've selected is connected and syncing data correctly. A sync error might be the cause of missing attributes.
 
-      3. **Optional.** Click **Add fallback source** or **Add additional source** (for manager email, additional username, and additional email) and add additional mappings as fallback or additional sources of the user attribute data. 
+      3. **Optional.** Click **Add fallback source** or **Add another source** (for manager email, additional username, and additional email) and add additional mappings as fallback or additional sources of the user attribute data. 
 
          In the case of fallback sources, C1 will iterate through the list you create here until it finds a source with the data it's looking for.
 

product/admin/automations.mdx

@@ -1,7 +1,7 @@
 ---
 title: "Create automations"
 og:title: "Create automations - C1 docs"
 og:description: "Automations are custom workflows that can streamline repetitive tasks like onboarding and offboarding, ensuring consistency and reducing manual effort."
 description: "Automations are custom workflows that can streamline repetitive tasks like onboarding and offboarding, ensuring consistency and reducing manual effort."
 sidebarTitle: "Automate custom workflows"
 ---
@@ -55,7 +55,7 @@
     Fill out the automation step form and click **Save**.
   </Step>
   <Step>
-    Click **+ Add step** again and repeat the process to add additional steps, as needed.
+    Click **Add step** again and repeat the process to add additional steps, as needed.
 
     If you need to reorder the automation steps, hover over the step and use the arrow keys.
 
@@ -212,7 +212,7 @@
 
 - **[Requestable automations](/product/admin/automation-actions)**: Let users trigger workflows from the self-service catalog, with approval flows and form inputs.
 - **[Functions](/product/admin/functions)**: Extend automations with custom TypeScript logic for use cases that go beyond built-in steps. See [using Functions in automations](/product/admin/functions-automations).
 - **[Workflow expressions](/product/admin/expressions-workflows)**: The `ctx` object, `{{ }}` template syntax, and data flow patterns for CEL in automations.
 - **[Triggers reference](/product/admin/automations-triggers-reference)**: Detailed configuration for all 11 trigger types.
 - **[Steps reference](/product/admin/automations-steps-reference)**: Detailed configuration for all 15 step types.
 - **[Expressions examples](/product/admin/expressions-examples)**: Copy-paste CEL patterns for common scenarios.

product/admin/campaigns.mdx

@@ -153,7 +153,7 @@
    </Tip>
 </Step>
 <Step>
-**Optional.** To surface app user profile attributes to reviewers during access reviews, find the **Attribute visibility** section and click **+ Add attribute**. For each attribute you want to show, select an app and the attribute key — for example, **department** on AWS PROD. Each app-attribute combination is configured as a separate entry. Reviewers see no attributes by default; only those you configure here will be visible.
+**Optional.** To surface app user profile attributes to reviewers during access reviews, find the **Attribute visibility** section and click **Add attribute**. For each attribute you want to show, select an app and the attribute key — for example, **department** on AWS PROD. Each app-attribute combination is configured as a separate entry. Reviewers see no attributes by default; only those you configure here will be visible.
 
 See [Map user attributes](/product/admin/attributes) to learn how attributes are defined in C1.
 </Step>
@@ -165,7 +165,7 @@
 
 <Steps>
 <Step>
-On the **Scope** tab of your campaign, find the **Grant types** section. By default, campaigns review grants held by users. Click **Change selection** if you want to review grants held by other kinds of principals instead:
+On the **Scope** tab of your campaign, find the **Grant type** section. By default, campaigns review grants held by users. Click **Change selection** if you want to review grants held by other kinds of principals instead:
 
    - **Users only** *(default)* — Review access grants held directly by users.
    - **Resources only** — Review access grants held by groups or roles instead of users.
@@ -234,7 +234,7 @@
 
 </Step>
 <Step>
-**Optional.** Find the **Account parameters** section of the page and click **Make selections**. 
+**Optional.** Find the **Account selection** section of the page and click **Make selections**. 
 
    If you don't make any selections here, all accounts with access to the apps or resources you selected above will be added to the campaign. If you want to narrow the focus of the UAR: 
 
@@ -256,7 +256,7 @@
 
 </Step>
 <Step>
-**Optional.** Find the **Grant parameters** section of the page and click **Make selections**. 
+**Optional.** Find the **Grant selection** section of the page and click **Make selections**. 
 
    If you don't make any selections here, all access grants of the apps or resources you selected above will be added to the campaign. If you want to narrow the focus of the UAR: 
 
@@ -492,7 +492,7 @@
    </Tip>
 </Step>
 <Step>
-**Optional.** To surface app user profile attributes to reviewers during access reviews, find the **Attribute visibility** section and click **+ Add attribute**. For each attribute you want to show, select an app and the attribute key — for example, **department** on AWS PROD. Each app-attribute combination is configured as a separate entry. Reviewers see no attributes by default; only those you configure here will be visible.
+**Optional.** To surface app user profile attributes to reviewers during access reviews, find the **Attribute visibility** section and click **Add attribute**. For each attribute you want to show, select an app and the attribute key — for example, **department** on AWS PROD. Each app-attribute combination is configured as a separate entry. Reviewers see no attributes by default; only those you configure here will be visible.
 
 See [Map user attributes](/product/admin/attributes) to learn how attributes are defined in C1.
 </Step>
@@ -504,7 +504,7 @@
 
 <Steps>
 <Step>
-On the **Scope** tab of your template, find the **Grant types** section. By default, campaigns review grants held by users. Click **Change selection** if you want campaigns made from this template to review grants held by other kinds of principals instead:
+On the **Scope** tab of your template, find the **Grant type** section. By default, campaigns review grants held by users. Click **Change selection** if you want campaigns made from this template to review grants held by other kinds of principals instead:
 
    - **Users only** *(default)* — Review access grants held directly by users.
    - **Resources only** — Review access grants held by groups or roles instead of users.
@@ -517,7 +517,7 @@
 
    - To run a UAR on user access to specific permissions, click **Review specific resources** and select resources, then click **Save**.
 
      When selecting specific resources, you can use the filter bar to narrow results by **Application**, **Resource type**, **Risk level**, and **Compliance framework**. Select one or more values for any filter to find matching entitlements. Filters use **OR** logic within a single filter type and **AND** logic across filter types. For example, selecting risk levels "High" and "Critical" along with compliance framework "SOX" returns entitlements that are (High OR Critical) AND (SOX).
 
      **OR**
 
@@ -566,7 +566,7 @@
       - [User profile attributes](/product/admin/attributes). For example, to run an access review campaign on all the AcmeApp users in your company with the job title "Engineer", create the parameter **User AcmeJob is Engineer**.
 </Step>
 <Step>
-**Optional.** Find the **Account parameters** section of the page and click **Make selections**. 
+**Optional.** Find the **Account selection** section of the page and click **Make selections**. 
 
    If you don't make any selections here, all accounts with access to the apps or resources you selected above will be added to the campaign. If you want to narrow the focus of the UAR: 
 
@@ -584,7 +584,7 @@
 
 </Step>
 <Step>
-**Optional.** Find the **Grant parameters** section of the page and click **Make selections**. 
+**Optional.** Find the **Grant selection** section of the page and click **Make selections**. 
 
    If you don't make any selections here, all access grants of the apps or resources you selected above will be added to the campaign. If you want to narrow the focus of the UAR: 
 

product/admin/customize-requests.mdx

@@ -1,13 +1,13 @@
 ---
 title: Add instructions and request forms to access requests
 og:title: Add instructions and request forms to access requests - C1 docs
 og:description: Use these tools to provide instructions on how to request access, and to collect needed information from requestors. 
 description: Use these tools to provide instructions on how to request access, and to collect needed information from requestors. 
 sidebarTitle: Add instructions and custom forms
 ---
 {/* Editor Refresh: 2026-05-29 */}
 
 ## Provide instructions to requestors
 
 You can set instructions on each application that will be shown to users when they request new access in the web UI or in Slack. 
 
@@ -43,9 +43,9 @@
 
 **Done.** Users requesting entitlements in this app will be shown your instructions. 
 
 ## Collect additional information from requestors using request forms 
 
 You can set up customized request forms that require requestors to provide additional information when making an access request in the web UI. (Request forms are not currently supported in Slack or Teams.) 
 
 <Frame>
 <img src="/images/product/assets/custom-forms-1.png" alt="Two screenshots side by side, with the left one displaying the request form creation drawer, and the right one showing the request form on an access request."/>
@@ -101,7 +101,7 @@
 </Step>
 </Steps>
 
-**Done.** The request form will now be shown whenever a user requests this entitlement via the **Requests** page or the **+ New request** form. 
+**Done.** The request form will now be shown whenever a user requests this entitlement via the **Requests** page or the **New request** form. 
 
 ### Add a request form to several entitlements in an app 
 
@@ -124,7 +124,7 @@
 Click **Submit**.
 </Step>
 </Steps>
-**Done.** The request form will now be shown whenever a user requests one of the selected entitlement via the **Requests** page or the **+ New request** page. 
+**Done.** The request form will now be shown whenever a user requests one of the selected entitlement via the **Requests** page or the **New request** page. 
 
 ### Create a new request form
 
@@ -157,7 +157,7 @@
 * Dropdown 
 </Step>
 <Step>
 Fill in the field label and provide dropdown options, helper text, a default value, and a placeholder, as needed. Helper text supports markdown — use it to add links, bold text, or lists to guide requesters. The required and available elements vary by field type. Here's an overview of how and where these elements are shown in the access request:
 
    <Frame>
    <img src="/images/product/assets/custom-forms-2.png" alt="A screenshot showing a request modal on the Requests page with a request form showing the four field types. Each field element is labeled with its type: the text field's field label reads Text field label, the placeholder value is Placeholder, and so on."/>

product/admin/enable-ai-access-management.mdx

@@ -8,7 +8,7 @@
 {/* Editor Refresh: 2026-05-08 */}
 
 <Note>
 **Activation required.** AI access management must be enabled for your tenant before you can use it. To get started, [contact the C1 support team](mailto:support@c1.ai) for a walkthrough.
 </Note>
 
 AIAM lets you govern which AI clients can call which tools on your behalf, and which end users are allowed to use them. Enabling AIAM for your tenant is a one-time task that requires the **Super Administrator** role. Configuring tenant defaults, registering MCP servers, governing tools, managing AI clients, and using kill switches can be performed by either a Super Administrator or a user with the [AI Governance Administrator](/product/admin/user-roles#ai-governance-administrator) role.
@@ -17,7 +17,7 @@
 
 ## Enable AIAM for your tenant
 
 Enabling AIAM exposes the AIAM surfaces (MCP servers, tools, AI clients, AIAM audit log) to admins. It does **not** automatically grant any end user access to any tool — every tool still has to be approved, added to a toolset, and bound to an access profile before it becomes requestable.
 
 <Steps>
 <Step>
@@ -37,7 +37,7 @@
 </Step>
 </Steps>
 
-Once enabled, **MCP servers**, **AI clients**, and the **AIAM audit log** appear in the tenant.
+Once enabled, **MCP servers**, **MCP clients**, and the **AIAM audit log** appear in the tenant.
 
 ## Configure tenant defaults
 
@@ -74,7 +74,7 @@
 
 ### Default tool classification
 
 When C1 discovers a new tool on a registered MCP server, it assigns the tool this initial state. Until an admin reviews and approves the tool, it cannot be added to a toolset and end users cannot request it.
 
 - **State**: Pending Review / Unset (recommended — keeps every newly-discovered tool out of end-user reach until you've reviewed it)
 - **Classification**: Unclassified (recommended)
@@ -95,13 +95,13 @@
 
 ### Require tool approval
 
 When on, every newly-discovered tool starts in **Pending Review** and must be approved by an admin before it can be added to a toolset. When off, tools become available to be added to toolsets immediately on discovery.
 
 - **Default**: On
 - **Recommended**: On for production tenants. Off is appropriate only for sandbox tenants where you're testing the end-to-end flow.
 
 <Note>
 Turning this off does not bypass access profile approval — end users still go through the access profile's approval policy when they request a toolset.
 </Note>
 
 ### Client lifecycle inactivity policy
@@ -141,10 +141,10 @@
 
 <Steps>
 <Step>
-In **Settings > System management**, find **Emergency kill switch**.
+In **Settings > System management**, find **Disable system features**.
 </Step>
 <Step>
-Click **Disable all AI access**.
+Toggle **Disable MCP traffic**.
 </Step>
 </Steps>
 

product/admin/managing-accounts.mdx

@@ -120,7 +120,7 @@
 
 Use **Configure columns** in the **Accounts** table header to adjust which columns are visible — toggle columns on or off and drag to reorder. Your layout is saved automatically.
 
-To export accounts data to CSV, click **Generate CSV** above the **Accounts** table. The **Download to CSV** drawer opens where you can choose which columns to include before generating the file.
+To export accounts data to CSV, click **Generate CSV** above the **Accounts** table. The **Download as CSV** drawer opens where you can choose which columns to include before generating the file.
 
 <Frame>
 ![A screenshot of a Slack application's Accounts tab in C1.](/images/product/assets/apps-accounts-3.png)
@@ -185,5 +185,5 @@
 Maybe. Depending on the revoke policy governing the entitlement, the revocation might require review and approval before the entitlement is removed from the account.
 </Tip>
 
 Once any required review and approval steps have been completed, the access will be removed from the account using the deprovisioning strategy set on the entitlement.
 

product/admin/managing-entitlements.mdx

@@ -54,7 +54,7 @@ Click **Create**.
 
 Use **Configure columns** in the **Entitlements** table header to adjust which columns are visible — toggle columns on or off and drag to reorder. Your layout is saved automatically. The table includes an **Owners** column showing the users responsible for each entitlement.
 
-To export entitlements data to CSV, click **Generate CSV** above the **Entitlements** table. The **Download to CSV** drawer opens where you can choose which columns to include before generating the file.
+To export entitlements data to CSV, click **Generate CSV** above the **Entitlements** table. The **Download as CSV** drawer opens where you can choose which columns to include before generating the file.
 
 ## Managing entitlements
 

product/admin/managing-resources.mdx

@@ -37,7 +37,7 @@
 
 Example use cases:
 
 * **Making new accounts requestable**: To allow users to request new accounts within an application, configure the access controls directly on the Access entitlement of the application's **Credential** resource.
 
 * **Running account-level access reviews**: If you need to perform an access review for all users who possess any account within a particular application, select the application's **Credential** resource as the target for the review.
 
@@ -51,7 +51,7 @@
 
 Use **Configure columns** in the **Resources** table header to adjust which columns are visible — toggle columns on or off and drag to reorder. Your layout is saved automatically.
 
-To export resources data to CSV, click **Generate CSV** above the **Resources** table. The **Download to CSV** drawer opens where you can choose which columns to include before generating the file.
+To export resources data to CSV, click **Generate CSV** above the **Resources** table. The **Download as CSV** drawer opens where you can choose which columns to include before generating the file.
 
 ## Managing resources
 

product/admin/mcp-server/google-analytics-admin.mdx

@@ -9,7 +9,7 @@
 {/* Editor Refresh: 2026-06-11 */}
 
 <Note>
 **Activation required.** AI access management must be enabled for your tenant before you can use it. To get started, [contact the C1 support team](mailto:support@c1.ai) for a walkthrough.
 </Note>
 
 The Google Analytics Admin MCP server lets you govern access to Google Analytics 4 configuration — accounts, properties, data streams, custom dimensions, conversions, and account-level user permissions — as tools your AI clients can call through C1.
@@ -117,7 +117,7 @@
 Follow [Register an MCP server](/product/admin/mcp-servers#register-an-mcp-server) and select **Google Analytics Admin** from the catalog.
 </Step>
 <Step>
-When you [configure authentication](/product/admin/mcp-servers#configure-authentication), choose **OAuth2 — JWT bearer** and provide the service account's JSON key and the scopes you need, such as `analytics.readonly` and `analytics.edit`.
+When you [configure authentication](/product/admin/mcp-servers#configure-authentication), choose **JWT Bearer (RFC 7523)** and provide the service account's JSON key and the scopes you need, such as `analytics.readonly` and `analytics.edit`.
 </Step>
 <Step>
 Save your changes. C1 starts a sync that discovers the tools the Google Analytics Admin server exposes.
@@ -139,7 +139,7 @@
 
 Each tool starts as either **Pending review** or automatically **Approved**, depending on the option chosen when the server was set up or your tenant's default tool settings in **AI** > **MCP** > **Settings**. See [Require tool approval](/product/admin/enable-ai-access-management#require-tool-approval) and [Default tool classification](/product/admin/enable-ai-access-management#default-tool-classification).
 
 Before anyone can call a Google Analytics Admin tool, it must be approved, added to a toolset, and bound to an access profile. Continue to [Govern tools and toolsets](/product/admin/tools-and-toolsets) to set this up.
 
 <Note>
 Tool discovery runs even if your credentials are incorrect, so seeing discovered tools doesn't confirm that authentication is working. You confirm your Google Analytics Admin credentials when an approved user successfully calls a Google Analytics Admin tool from their AI client.

product/admin/mcp-server/google-drive.mdx

@@ -9,7 +9,7 @@
 {/* Editor Refresh: 2026-06-11 */}
 
 <Note>
 **Activation required.** AI access management must be enabled for your tenant before you can use it. To get started, [contact the C1 support team](mailto:support@c1.ai) for a walkthrough.
 </Note>
 
 The Google Drive MCP server lets you govern access to Google Drive — files, folders, shared drives, permissions, comments, and revisions — as tools your AI clients can call through C1.
@@ -116,7 +116,7 @@
 Follow [Register an MCP server](/product/admin/mcp-servers#register-an-mcp-server) and select **Google Drive** from the catalog.
 </Step>
 <Step>
-When you [configure authentication](/product/admin/mcp-servers#configure-authentication), choose **OAuth2 — JWT bearer** and provide the service account's JSON key and the scopes you delegated.
+When you [configure authentication](/product/admin/mcp-servers#configure-authentication), choose **JWT Bearer (RFC 7523)** and provide the service account's JSON key and the scopes you delegated.
 </Step>
 <Step>
 Save your changes. C1 starts a sync that discovers the tools the Google Drive server exposes.
@@ -138,7 +138,7 @@
 
 Each tool starts as either **Pending review** or automatically **Approved**, depending on the option chosen when the server was set up or your tenant's default tool settings in **AI** > **MCP** > **Settings**. See [Require tool approval](/product/admin/enable-ai-access-management#require-tool-approval) and [Default tool classification](/product/admin/enable-ai-access-management#default-tool-classification).
 
 Before anyone can call a Google Drive tool, it must be approved, added to a toolset, and bound to an access profile. Continue to [Govern tools and toolsets](/product/admin/tools-and-toolsets) to set this up.
 
 <Note>
 Tool discovery runs even if your credentials are incorrect, so seeing discovered tools doesn't confirm that authentication is working. You confirm your Google Drive credentials when an approved user successfully calls a Google Drive tool from their AI client.

product/admin/mcp-server/looker.mdx

@@ -9,7 +9,7 @@
 {/* Editor Refresh: 2026-06-11 */}
 
 <Note>
 **Activation required.** AI access management must be enabled for your tenant before you can use it. To get started, [contact the C1 support team](mailto:support@c1.ai) for a walkthrough.
 </Note>
 
 The Looker MCP server lets you govern access to Looker — dashboards, looks, queries, explores, content, and users — as tools your AI clients can call through C1.
@@ -67,7 +67,7 @@
 Enter your Looker instance URL when prompted.
 </Step>
 <Step>
-When you [configure authentication](/product/admin/mcp-servers#configure-authentication), choose **OAuth2 — client credentials** and enter your Looker **client ID** and **client secret**.
+When you [configure authentication](/product/admin/mcp-servers#configure-authentication), choose **Client credentials** and enter your Looker **client ID** and **client secret**.
 </Step>
 <Step>
 Save your changes. C1 starts a sync that discovers the tools the Looker server exposes.
@@ -80,7 +80,7 @@
 
 Each tool starts as either **Pending review** or automatically **Approved**, depending on the option chosen when the server was set up or your tenant's default tool settings in **AI** > **MCP** > **Settings**. See [Require tool approval](/product/admin/enable-ai-access-management#require-tool-approval) and [Default tool classification](/product/admin/enable-ai-access-management#default-tool-classification).
 
 Before anyone can call a Looker tool, it must be approved, added to a toolset, and bound to an access profile. Continue to [Govern tools and toolsets](/product/admin/tools-and-toolsets) to set this up.
 
 <Note>
 Tool discovery runs even if your credentials are incorrect, so seeing discovered tools doesn't confirm that authentication is working. You confirm your Looker credentials when an approved user successfully calls a Looker tool from their AI client.

product/admin/mcp-server/wiz.mdx

@@ -9,7 +9,7 @@
 {/* Editor Refresh: 2026-06-11 */}
 
 <Note>
 **Activation required.** AI access management must be enabled for your tenant before you can use it. To get started, [contact the C1 support team](mailto:support@c1.ai) for a walkthrough.
 </Note>
 
 The Wiz MCP server lets you govern access to the Wiz cloud security platform — issues, vulnerabilities, cloud resources, and other data exposed by the Wiz GraphQL API — as tools your AI clients can call through C1.
@@ -69,7 +69,7 @@
 Enter your regional Wiz API endpoint, such as `https://api.us1.app.wiz.io`.
 </Step>
 <Step>
-When you [configure authentication](/product/admin/mcp-servers#configure-authentication), choose **OAuth2 — client credentials** and enter the service account's **client ID** and **client secret**.
+When you [configure authentication](/product/admin/mcp-servers#configure-authentication), choose **Client credentials** and enter the service account's **client ID** and **client secret**.
 </Step>
 <Step>
 Save your changes. C1 starts a sync that discovers the tools the Wiz server exposes.
@@ -82,7 +82,7 @@
 
 Each tool starts as either **Pending review** or automatically **Approved**, depending on the option chosen when the server was set up or your tenant's default tool settings in **AI** > **MCP** > **Settings**. See [Require tool approval](/product/admin/enable-ai-access-management#require-tool-approval) and [Default tool classification](/product/admin/enable-ai-access-management#default-tool-classification).
 
 Before anyone can call a Wiz tool, it must be approved, added to a toolset, and bound to an access profile. Continue to [Govern tools and toolsets](/product/admin/tools-and-toolsets) to set this up.
 
 <Note>
 Tool discovery runs even if your credentials are incorrect, so seeing discovered tools doesn't confirm that authentication is working. You confirm your Wiz credentials when an approved user successfully calls a Wiz tool from their AI client.

product/admin/mcp-servers.mdx

@@ -8,7 +8,7 @@
 {/* Editor Refresh: 2026-05-29 */}
 
 <Note>
 **Activation required.** AI access management must be enabled for your tenant before you can use it. To get started, [contact the C1 support team](mailto:support@c1.ai) for a walkthrough.
 </Note>
 
 This page walks through registering an MCP server with C1, linking it to a C1 application, and configuring authentication. Once registered, C1 automatically discovers the tools the server exposes — see [Govern tools and toolsets](/product/admin/tools-and-toolsets) for what to do next.
@@ -34,7 +34,7 @@
 <Step>
 Select which application the MCP server should be registered under:
 
 - **Add to an existing managed or unmanaged app** — select this if you already have a connector-backed C1 app for the same downstream service. The MCP server registers under that app and inherits its user assignments.
 - **Create a new app** — select this if you do not have a connector-backed app for the service. C1 creates a new app for the MCP server. You will need to add users to this app before they can request access to its tools.
 </Step>
 <Step>
@@ -53,12 +53,12 @@
 | **Bearer token** | A single shared service account | Simple integrations where per-user attribution downstream isn't required |
 | **Custom header** | A single shared identity via a custom HTTP header (for example, an API key) | Services that authenticate via a non-standard header or API key |
 | **Basic auth** | A single shared identity via username and password | Services that use HTTP Basic authentication |
-| **OAuth2 — client credentials** | A single shared OAuth client | Machine-to-machine OAuth where per-user identity isn't needed |
+| **Client credentials** | A single shared OAuth client | Machine-to-machine OAuth where per-user identity isn't needed |
 | **OAuth2 — service mode** | A single shared identity (admin authenticates once) | When the downstream requires an OAuth auth code flow but a single shared credential is acceptable |
 | **OAuth2 — per-user passthrough** | Each end user, with their own credentials | When the downstream needs per-user identity (Google Workspace, GitHub, Salesforce, and so on) |
-| **OAuth2 — JWT bearer** | A service identity via signed JWT | Services that support certificate-based or JWT-based auth (for example, Tableau or Google service accounts) |
+| **JWT Bearer (RFC 7523)** | A service identity via signed JWT | Services that support certificate-based or JWT-based auth (for example, Tableau or Google service accounts) |
 
 For per-user OAuth passthrough, C1 vaults each user's downstream tokens and auto-refreshes them so end users don't hit token expiry mid-session.
 
 To configure auth:
 
@@ -79,7 +79,7 @@
   - **Per-user (each user submits their own)**: No credentials to enter. Each user provides their own username and password when they connect, and MCP requests run under their individual identity.
 - **Client credentials** — enter client ID, client secret, and token URL.
 - **Service mode** — enter client ID, client secret, authorization URL, token URL, and scopes. An admin completes the OAuth flow once; all users share that credential.
 - **Per-user passthrough** — enter client ID, client secret, authorization URL, token URL, and scopes. End users see a Connect prompt the first time their AI client calls a tool from this server.
 - **JWT bearer** — enter the issuer, private key, subject, audience, token URL, and scopes.
 
 If the server supports OAuth Dynamic Client Registration (DCR), you can skip entering a client ID and secret entirely. Toggle on **Use dynamic client registration** — C1 registers itself with the server's authorization server automatically.
@@ -95,7 +95,7 @@
 | :--- | :--- | :--- |
 | **Authentication** | Required | See above |
 | **Data sensitivity** | Optional | Metadata tag on the server (low / medium / high). Surfaces in the catalog and audit log; no enforcement |
 | **Tool prefix** | Optional; required if multiple servers under one app | Prepended to tool names so AI clients can disambiguate (for example, `gh_` vs `gl_` for two Git providers). C1 generates a default prefix if you don't set one. |
 
 ## What happens after registration
 

product/admin/policies.mdx

@@ -117,7 +117,7 @@
 
    - Use the **Basic** condition builder to construct a rule from a combination of entitlements and [profile attributes](/product/admin/attributes) (see note below on which profile attributes are supported), with the option to add **and** and **or** statements to refine the rule.
    <Tip>
    **Supported attributes in the basic condition builder** The value input field in the basic condition builder currently only supports string values. Certain attributes are stored as enums (fixed lists of values) or arrays (multiple values), which cannot be correctly parsed when entered as a simple string in the basic builder. If you use these attributes in the basic builder, the system will treat the input as a literal string, and the policy or membership rule may not behave as expected.
 
    The following attributes are not supported in the basic condition builder:
 
@@ -129,7 +129,7 @@
 
    If you need to use any of the attributes listed above, you must compose a CEL expression in the **Expression** field.
    </Tip>
    - Use the **Expression** field to to compose a [CEL expression](/product/admin/expressions) that describes the membership rule.
 </Step>
 <Step>
 In the **Then perform this action:** section of the rule, select an automatic action (the exact actions vary by policy type) or **Execute a workflow** to wait for a condition to be met or assign the task to a reviewer workflow (see below).
@@ -137,7 +137,7 @@
    If necessary, click **Add step** to add additional actions or workflows to the rule.
 </Step>
 <Step>
-Repeat the **Add another rule** process, adding as many conditional rules as needed. If necessary, you can use the arrow keys to change the order of your rules.
+Repeat the **Add rule** process, adding as many conditional rules as needed. If necessary, you can use the arrow keys to change the order of your rules.
 
    Remember, for best results place more specific rules before less specific rules.
 </Step>
@@ -244,7 +244,7 @@
 
 3. Set whether the reviewer (or the fallback reviewer, if applicable) can reassign the task, and whether reassigned tasks require a reason for their reassignment.
 
    Use the **Limit reassignment to** field to create an allowlist of users who the task can be reassigned to. If the task can be reassigned to any user, leave this field blank. 
 
 3. Set whether this step allows the task to be reassigned to an assigned delegate, either a [delegate set by an admin](/product/admin/delegate#set-a-delegate-for-another-user), such as for an executive or employee out on long-term leave, or a [delegate set by an individual user](/product/admin/delegate#set-your-own-delegate) while they are out of office.  
 
@@ -252,11 +252,11 @@
 
 4. **Request and review policies only.** Set whether this step requires a distinct approver. This means a user who approved an earlier step in the workflow cannot approve this step, ensuring a different set of eyes reviews each stage.
 
    If **Require distinct approvers** is enabled, the system automatically assigns the task to an approver who has not previously approved the request. If the policy can't find a distinct approver, it will automatically route the approval to fallback users (Campaign Admins or Super Admins).
 
 5. Set whether approvals and denials require the reviewer to enter a justification for their choice.
 
 6. **Optional.** If desired, check to enable **Trigger SLA violation after** and set the timeframe for a service-level agreement (SLA) to kick in. If no action has been taken on the task when the time elapses, select what happens next:
 
    * **Use a new policy** - Select a different policy from the list to take over the approval process.
 

product/admin/provisioning.mdx

@@ -21,7 +21,7 @@
 Direct provisioning is the default provisioning strategy for apps with a connector.
 </Tip>
 
 This is the easiest method. Provisioning-enabled C1 connectors complete the provisioning process directly, without any input needed from you. C1 can provision fine-grained entitlements and permissions directly in the connected application or infrastructure. By default, C1 will use the connector when provisioning or deprovisioning access. To determine if a connector supports provisioning, see the connector's documentation.
 
 ## Method 2: Linked entitlements
 
@@ -35,9 +35,9 @@
 
 Examples of linked entitlements:
 
 - In Microsoft Entra, several groups are assigned to the application for access control.
 - In Okta, several push groups are used to SCIM group memberships to the app.
 - In Okta, AWS access is controlled using custom attributes that are added to the SAML assertion at login time.
 
 In each example above, access is "controlled" by assigning the user to the entitlement (such as group membership) in the SSO directory or identity provider.
 
@@ -95,17 +95,17 @@
 If there is an error or issue in provisioning, manual provisioning is used as the fallback method. In this scenario, the request is assigned to the application owner to resolve the issue.
 </Warning>
 
-## Method 4: Ticket-based provisioning
+## Method 4: External ticketing
 
 <Tip>
 **When to use?**
 
 Use ticket-based provisioning if you need access requests to flow through your helpdesk.
 </Tip>
 
 C1 supports helpdesk ticket creation as a method for provisioning access. To use ticket provisioning, you'll first need to add a connector that supports ticket provisioning. Examples of ticketing-enabled connectors are [Jira](/baton/jira/) and [ServiceNow](/baton/servicenow/). 
 
 Once a connector with ticketing is added, configure how C1 will create tickets in the system (see [External ticketing](/product/admin/external-ticketing) for instructions), then set provisioning to use the external ticketing option. Once set up, a helpdesk ticket will be automatically created any time provisioning is required. C1 will track the progress of the helpdesk ticket and update or close the provisioning task accordingly. 
 
 ## Method 5: Webhook provisioning
 
@@ -152,7 +152,7 @@
 If you have multiple steps for provisioning access, such as "put the user in an IdP group, then directly provision the entitlement in another application".
 </Tip>
 
 Custom provisioning allows for significant flexibility when it comes to provisioning access. Multi-step provisioning allows you to perform a series of steps for provisioning access, such as "send a webhook and then create a helpdesk ticket and then directly assign the permission in the app".
 
 To configure multi-step provisioning: 
 
@@ -174,25 +174,25 @@
 </Step>
 </Steps>
 
 ## Deprovisioning 
 
 The process of **deprovisioning** (removing a user's access) is automatically handled by C1 and generally mirrors the configured provisioning method.
 
 By **default**, C1 attempts to infer and perform the **inverse action** of the configured provisioning method for an entitlement. For example:
 
 * If the provisioning method is **Connector provisioning**, the system will attempt to use the connector to directly deprovision the entitlement in the target application. (Not all connectors support deprovisioning, see the connector's docs for details.)
 
 * If the provisioning method is **Linked entitlements**, the system will remove the linked entitlement in the SSO directory or identity provider.
 
-* If the provisioning method is **Ticket-based provisioning**, a helpdesk ticket will be created to initiate the removal of access.
+* If the provisioning method is **External ticketing**, a helpdesk ticket will be created to initiate the removal of access.
 
 ### Set a custom deprovisioning flow for an entitlement
 
 You have the option to set a specific deprovisioning flow that is different from the provisioning method for any entitlement.
 
 This is useful if the steps required to remove access are different or more complex than the steps used to grant access.
 
 To configure a custom deprovisioning flow for an entitlement:
 
 <Steps>
 <Step>
@@ -208,10 +208,10 @@
 In the **Deprovisioning** section of the page, click **Edit**. 
 </Step>
 <Step>
 Select your desired deprovisioning method, and configure the selected method. 
 </Step>
 <Step>
 Use the **Add step** controls to add as many deprovisioning steps as are needed. Make sure to add the deprovisioning steps in the order you want them to be applied. 
 </Step>
 <Step>
 Click **Save**.

product/admin/role-mining.mdx

@@ -29,10 +29,10 @@ If you're starting from a specific entitlement and want to know who should have
     Navigate to **Governance** > **Role mining**.
   </Step>
   <Step>
-    In the **Filter** section, click **+ Add filter**. Select a user attribute — such as Department, Job title, Manager, or Employment status — then select one or more values.
+    In the **Filter** section, click **Add filter**. Select a user attribute — such as Department, Job title, Manager, or Employment status — then select one or more values.
   </Step>
   <Step>
-    Add more filters as needed with **+ Add filter**. C1 updates the results as you build your cohort.
+    Add more filters as needed with **Add filter**. C1 updates the results as you build your cohort.
   </Step>
 </Steps>
 

product/admin/secret-sharing.mdx

@@ -13,7 +13,7 @@
 Secret sharing is designed so that C1 never has access to your secrets. Encryption happens in your browser, before anything leaves your device. Here's how a secret moves from creation to delivery:
 
 1. **Create** — choose who can access the secret, add your content, and decide how long it should stay available and how many times it can be viewed.
 2. **Encrypt** — your browser encrypts the content before upload. C1 stores only the encrypted result and never sees your plaintext.
 3. **Share** — copy the generated link and send it to recipients through whatever channel you choose: email, Slack, a ticket, or anything else.
 4. **Access** — recipients click the link and authenticate (SSO for internal users, a one-time email magic link for external contacts), then view or download the content.
 
@@ -43,9 +43,9 @@
 | Format | Description |
 | :--- | :--- |
 | **File** | Any file up to 1 GB — documents, certificates, credential files, SSH keys. |
 | **Text** | Passwords, API keys, tokens, or any sensitive plaintext (up to 64 KB). |
 | **JSON** | Service account credentials or config objects, with syntax validation. |
 | **YAML** | Kubernetes secrets, Helm values, or CI/CD configs. |
 | **Env** | Environment variables in KEY=Value format — supports paste from `.env` files. |
 </Step>
 <Step>
@@ -80,7 +80,7 @@
 Authenticate with your organization's SSO if you're not already signed in.
 </Step>
 <Step>
-Click **Reveal content** or **Download file**.
+Click **Reveal secret** or **Download file**.
 </Step>
 </Steps>
 </Tab>
@@ -96,7 +96,7 @@
 Click the magic link in your inbox. The link expires in 15 minutes and can only be used once.
 </Step>
 <Step>
-Click **Reveal content** or **Download file**.
+Click **Reveal secret** or **Download file**.
 </Step>
 </Steps>
 
@@ -159,11 +159,11 @@
 
 ## Secret-sharing security
 
 Content is encrypted in your browser before it's uploaded. C1 stores only encrypted blobs and never sees your plaintext. When a recipient accesses a secret, an isolated vault service decrypts and delivers the content to that specific recipient. Plaintext is never stored, logged, or persisted.
 
 | Control | Detail |
 | :--- | :--- |
 | **Browser-side encryption** | Content is encrypted before upload; plaintext never touches C1 servers or logs. |
 | **Isolated decryption** | A dedicated vault service handles decryption, with access controlled by AWS KMS with hardware security modules. |
 | **View limits and expiration** | Content is permanently deleted after the view limit is reached or the expiration time passes. |
 | **Magic link protection** | Magic link tokens are single-use and expire after 15 minutes. |
@@ -173,7 +173,7 @@
 
 <AccordionGroup>
   <Accordion title="Can C1 employees see my secrets?">
     Absolutely not. C1 stores only encrypted blobs. Decryption occurs in an isolated vault service and plaintext is never stored or logged.
   </Accordion>
 
   <Accordion title="What happens when a secret expires or is burned?">

product/admin/service-principals/custom-oidc.mdx

@@ -77,11 +77,11 @@
 - Always validate the `sub` claim or an equivalent unique identifier
 - Use additional claims for defense-in-depth: organization, project, environment
 - CEL string functions are available: `contains()`, `startsWith()`, `endsWith()`, `matches()`, `size()`
 - For namespaced claims (like AWS), use bracket notation: `claims["https://example.com/"].field`
 - Expressions are limited to 1,024 bytes
 
 {/*<Tip>
-Use the **Test CEL** tool at **Settings** > **Workload Federation** to validate your expressions against sample claims before deploying.
+Use the **Test expression** tool at **Settings** > **Workload Federation** to validate your expressions against sample claims before deploying.
 </Tip>*/}
 
 ## Using with C1 tools