HOLD FOR LAUNCH private bridge MCP server setup guide

docs.json

@@ -107,6 +107,7 @@
               {
                 "group": "MCP server setup guides",
                 "pages": [
+                  "product/admin//mcp-server/mcp-bridge",
                   "product/admin/mcp-server/apollo",
                   "product/admin/mcp-server/auth0",
                   "product/admin/mcp-server/azure-devops",

product/admin/mcp-server/mcp-bridge.mdx

@@ -0,0 +1,315 @@
+---
+title: Connect a private MCP server through a bridge
+description: Route AI tool calls to an MCP server running in your private network — no inbound firewall rules needed.
+og:title: Connect a private MCP server through a bridge - C1 docs
+og:description: Route AI tool calls to an MCP server running in your private network — no inbound firewall rules needed.
+sidebarTitle: Private bridge
+---
+
+{/* Editor Refresh: 2026-06-25 */}
+
+<Note>
+**Activation required.** AI access management must be enabled for your tenant, and private bridge connectivity must be turned on separately. To get started, [contact the C1 support team](mailto:support@c1.ai).
+</Note>
+
+If your MCP server runs in a private network — a laptop, a VM, or a cluster — and you can't or don't want to open inbound firewall rules, you can reach it through a **bridge**. You run a small agent (`bridge-client`) next to your server; it dials out to C1 and holds a tunnel open. C1 sends incoming tool calls back down that tunnel, so nothing in your network needs to listen for inbound connections.
+
+Setup has two halves that must match each other:
+
+1. A **bridge config** (YAML) that tells `bridge-client` where your MCP server is and what to advertise to C1.
+2. An **MCP server registration** in C1 that points C1 at the advertised service over the bridge.
+
+## Before you begin
+
+- Your MCP server must be running and reachable from wherever you'll run `bridge-client`. Have its `host:port`, endpoint path (typically `/mcp`), and transport (`streamable-http` or `sse`) ready.
+- Download `bridge-client` from the [C1 download center](https://dist.conductorone.com/ConductorOne/bridge-client). Linux and macOS binaries and container images are available there.
+- **Creating a bridge** requires the **Connector Administrator** or **Super Administrator** role.
+- **Registering the MCP server** requires the **Editor** role on the destination app.
+
+## Step 1 — Create a bridge in C1
+
+Creating a bridge issues the credentials that `bridge-client` uses to authenticate to C1.
+
+<Steps>
+<Step>
+In C1, go to **Settings** > **Bridges**.
+</Step>
+<Step>
+Give it a display name (for example, `my-laptop` or `prod-vpc-east`) and optionally a description, then click **Create bridge**. C1 navigates to the bridge's detail page.
+</Step>
+<Step>
+On the bridge detail page, find the **Credentials** card and click **Create credential**. (On a bridge that already has an active credential, this button is labeled **Rotate credential** instead.)
+</Step>
+<Step>
+Copy the **Client ID** and **Client secret** from the dialog.
+</Step>
+</Steps>
+
+The bridge is created in C1. You'll add the credentials to your config in the next step.
+
+<Warning>
+The client secret is shown only once. Copy it now — you'll paste it into the bridge config in the next step.
+</Warning>
+
+## Step 2 — Write the bridge config
+
+Create a file called `bridge.yaml`. Set the credentials from Step 1, and add a port entry that points to your local MCP server.
+
+```yaml
+version: 1
+bridge:
+  client_id:     "<Client ID from Step 1>"
+  client_secret: "<Client secret from Step 1>"
+  ports:
+    - name: my-mcp                    # service name — you'll select this in C1
+      listen_port: 8080               # port advertised on the bridge (any free port 1–65535)
+      backend: "127.0.0.1:8000"       # where your MCP server actually listens
+      service_type: MCP_NATIVE        # MCP_NATIVE for a native MCP server
+      service_path: /mcp              # your MCP server's endpoint path
+      transport_type: streamable-http # streamable-http or sse
+```
+
+### Port field reference
+
+| Field | Required | Description |
+| :--- | :--- | :--- |
+| `listen_port` | Yes | Port advertised on the bridge (1–65535). Must be unique within the config. |
+| `backend` | Yes | Local `host:port` that `bridge-client` dials — where your MCP server listens. |
+| `name` | Recommended | Service name shown in C1. You select this name when registering the MCP server. Must be unique within the config. |
+| `service_type` | No | `MCP_NATIVE` (native MCP server), `HOSTED` (hosted HTTP MCP), or `RAW` (opaque TCP). |
+| `service_path` | No | The MCP endpoint path, for example `/mcp`. |
+| `transport_type` | No | `streamable-http` or `sse` for an MCP server, or `http` for a hosted HTTP service. |
+
+<Note>
+The `service_path` and `transport_type` you set here are what C1 uses when routing tool calls. The registration wizard in Step 4 doesn't let you override them, so set them correctly now.
+</Note>
+
+You can expose more than one local service by adding more entries under `ports:`.
+
+### Other ways to supply config
+
+The YAML literals above aren't the only option. Both are covered in full in the [bridge setup guide](https://dist.conductorone.com/ConductorOne/bridge-client):
+
+- **Environment variables.** Instead of a config file, set `C1_BRIDGE_CLIENT_ID`, `C1_BRIDGE_CLIENT_SECRET`, and a single service via `C1_BRIDGE_SERVICE_LISTEN_PORT` and `C1_BRIDGE_SERVICE_BACKEND` (plus optional `C1_BRIDGE_SERVICE_NAME`, `_TYPE`, `_PATH`, and `_TRANSPORT_TYPE`).
+- **HashiCorp Vault.** Keep non-secret fields in YAML and pull sensitive ones (such as `client_secret`) from a HashiCorp Vault backend, so no secret ever lives in the config file.
+
+#### Resolve secrets from HashiCorp Vault
+
+Add a top-level `secret_backend:` block selecting Vault, and a top-level `secrets:` map that points each sensitive field at a `"<secret-id>:<key>"` locator. At startup `bridge-client` fetches each value and writes it into the matching `bridge:` field before connecting, so a field resolved from Vault doesn't need a literal in the YAML.
+
+```yaml
+version: 1
+bridge:
+  client_id: "<Client ID from Step 1>"
+  # client_secret omitted — resolved from Vault (see secrets: below)
+  ports:
+    - name: my-mcp
+      listen_port: 8080
+      backend: "127.0.0.1:8000"
+      service_type: MCP_NATIVE
+      service_path: /mcp
+      transport_type: streamable-http
+
+secret_backend:
+  type: vault
+  vault:
+    url:   "https://vault.example.com"   # or set VAULT_ADDR in the environment
+    mount: "kv"                          # the KV secrets-engine mount path
+    kvapi: 2                             # KV engine version: 1 or 2
+    token: "hvs.XXXX"                    # or set VAULT_TOKEN in the environment
+
+secrets:
+  client_secret: "bridge-creds:client_secret"
+```
+
+## Step 3 — Run the bridge
+
+Run `bridge-client` inside the same network as your MCP server. Select your deployment method:
+
+<Tabs>
+<Tab title="Binary">
+
+Start the agent. It runs continuously and holds the tunnel open:
+
+```bash
+bridge-client --config bridge.yaml
+```
+
+</Tab>
+<Tab title="Docker">
+
+Run the agent:
+
+```sh
+docker run --rm \
+  -v /etc/c1/bridge.yaml:/etc/c1/bridge.yaml:ro \
+  public.ecr.aws/conductorone/bridge-client:<version> \
+  --config /etc/c1/bridge.yaml
+```
+
+</Tab>
+<Tab title="Kubernetes">
+
+Create a `Secret` to hold the config (use a `Secret`, not a `ConfigMap`, so the client secret stays encrypted at rest):
+
+```yaml
+# bridge-secret.yaml
+apiVersion: v1
+kind: Secret
+metadata:
+  name: bridge-config
+type: Opaque
+stringData:
+  bridge.yaml: |
+    version: 1
+    bridge:
+      client_id:     "<Client ID from Step 1>"
+      client_secret: "<Client secret from Step 1>"
+      ports:
+        - name: my-mcp
+          listen_port: 8080
+          backend: "127.0.0.1:8000"
+          service_type: MCP_NATIVE
+          service_path: /mcp
+          transport_type: streamable-http
+```
+
+Then create the Deployment:
+
+```yaml
+# bridge-deployment.yaml
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  name: bridge-client
+  labels:
+    app: bridge-client
+spec:
+  selector:
+    matchLabels:
+      app: bridge-client
+  template:
+    metadata:
+      labels:
+        app: bridge-client
+    spec:
+      containers:
+      - name: bridge-client
+        image: public.ecr.aws/conductorone/bridge-client:<version>
+        args: ["--config", "/etc/c1/bridge.yaml"]
+        volumeMounts:
+        - name: bridge-config
+          mountPath: /etc/c1
+          readOnly: true
+      volumes:
+      - name: bridge-config
+        secret:
+          secretName: bridge-config
+```
+
+Apply both:
+
+```sh
+kubectl apply -f bridge-secret.yaml
+kubectl apply -f bridge-deployment.yaml
+```
+
+</Tab>
+</Tabs>
+
+After a few seconds, the bridge status changes to **Connected** in **Settings** > **Bridges**, and the service you configured appears on the bridge detail page.
+
+## Step 4 — Register the MCP server in C1
+
+With the bridge running, register the server in C1 so its tools are available for governance.
+
+<Steps>
+<Step>
+Open the app you want the MCP server registered under, go to its **MCP servers** tab, and click **Add MCP server**.
+
+If you're starting from the tenant-wide MCP servers page (**Integrations** > **MCP servers**) instead, the wizard adds a **Choose app** step so you can pick or create the destination app.
+</Step>
+<Step>
+Under **Choose a server**, select **External MCP server** — "Connect to an external MCP server by URL."
+</Step>
+<Step>
+Under **Connectivity**, select **Private bridge** — "Route through a C1 Bridge running in your network." Then set:
+
+- **Bridge** — the bridge you created in Step 1.
+- **Service** — the service your bridge advertised, which is the `name` field from `bridge.yaml` (`my-mcp` in the example).
+</Step>
+<Step>
+Under **Configure**, enter a display name for the server. The **Server URL** field is read-only — it's resolved automatically from the bridge service you selected.
+
+In the **Authentication** section, pick the **Authentication method** C1 uses to reach your server — **Bearer token**, **Custom header**, **Basic auth**, or **OAuth2** — and enter the credentials it requires. Then click **Add server**.
+</Step>
+</Steps>
+
+C1 connects to your server over the bridge and begins tool discovery.
+
+<Note>
+A user can only call a tool once they're an **app user** of the app the server is registered under. New external apps start with no app users. When you register from an existing app that has none, the wizard inserts a **Link users** step to populate them by linking an entitlement from another app. When you start from the tenant-wide MCP servers page instead, you get the **Choose app** step (not **Link users**) — populate app users afterward from the app's settings. See [Calling the tools from an AI client](#calling-the-tools-from-an-ai-client) for the full set of ways to do this.
+</Note>
+
+## Step 5 — Review discovered tools
+
+After you click **Add server**, C1 connects to your MCP server over the bridge and pulls its tool list. The wizard's final step shows these discovered tools.
+
+C1 records each tool's name, description, and input schema exactly as your MCP server advertises them, and surfaces that text to AI clients during discovery. The agent relies on it to decide which tool fits a request — so clear, accurate tool descriptions and schemas on your server directly affect how reliably the right tool gets found and called.
+
+Each tool:
+
+- Becomes its own **entitlement** in C1 — access is requested, granted, and reviewed like any other entitlement.
+- Is **auto-classified** in the **Classification** column; you can change the classification.
+- Starts with **State** set to **Unset**. Flip the toggle to **Enabled** to allow calls to that tool, or **Disabled** to block it for everyone.
+
+You don't need to finish reviewing tools in the wizard. Click **Done** to close it, or **Open server** to go to the server detail page. New tools added to the server appear there automatically after discovery — there's no manual sync button, so if a tool isn't showing yet, wait a moment and refresh.
+
+<Note>
+Setting a tool's state to **Enabled** makes it callable only by users who hold a grant for it — it doesn't grant access on its own. To grant access, add the tool to an MCP access profile and assign that profile to users. See [Govern tools and toolsets](/product/admin/tools-and-toolsets).
+</Note>
+
+## Step 6 — Verify the connection
+
+- In **Settings** > **Bridges**, the bridge shows **Connected**, with your service listed.
+- On the server's **Tools** tab in C1, the discovered tools appear.
+- On the server's **Details** tab, **Test credentials** succeeds and reports the number of tools discovered over the bridge.
+
+If something looks off, check the `bridge-client` logs. For a binary deployment, logs go to stdout/stderr. For Kubernetes:
+
+```sh
+kubectl logs -l app=bridge-client -f
+```
+
+## Calling the tools from an AI client
+
+Once the bridge is running and tools are approved, your users reach them from their AI clients (Claude Code, Claude Desktop, Cursor, VS Code) through C1's MCP gateway — not through the bridge directly. C1 authenticates the user, enforces tool governance, and routes each call through the bridge to your local server.
+
+By default, these clients use **code mode**: instead of listing each tool as its own named tool, C1 exposes discovery and execution entrypoints (`describe` and `execute`), and the agent finds the tools it needs and invokes them by writing short code. Your bridged tools won't appear one by one in the client's tool list — that's expected, not a discovery failure. Governance is unchanged: every underlying call still runs the same per-tool checks — the tool must be **Enabled** and the caller must hold a grant. Code mode is a tenant-level AI governance setting (on by default); with it off — or for **Service** and **Ephemeral** client types — C1 instead exposes each enabled tool as a directly named tool.
+
+<Note>
+A call only executes when the requesting user is an **app user** of the server's app and holds a grant for the tool. If the caller isn't yet an app user, the call opens an access request instead of running. App users come from the destination app's account sources. Populate them by linking an entitlement from another app (the **Link users** step during registration, or linked entitlements later in the app's settings), by importing a CSV of app users, or — if the app is backed by a connector — by syncing them from the connector.
+</Note>
+
+For end-user setup instructions, see [Connect your MCP client to C1](/product/how-to/connect-mcp-client).
+
+## Troubleshooting
+
+**Bridge never reaches Connected**
+Re-check `client_id` and `client_secret`. The secret is shown only once — if you didn't capture it, rotate the credential and try again. Check the `bridge-client` logs for an authentication error.
+
+**First tool call right after connecting fails with EOF or "failed to connect to external MCP server"**
+The connection can be slow on the very first call while the path warms up. Retry once — subsequent calls succeed.
+
+**Tool calls fail with connection refused or timeout**
+The `backend` `host:port` in your config is wrong, or the MCP server isn't running there. Confirm the server is up and reachable from wherever `bridge-client` is running.
+
+**Connected, but tool calls return errors**
+Check `service_path` and `transport_type` in `bridge.yaml`. The `service_path` must match the actual endpoint path your MCP server serves (for example, `/mcp`), and `transport_type` must match its transport. These values come from the config — the registration wizard doesn't let you override them. Also confirm you selected the right service in Step 4.
+
+## Rotate or revoke bridge credentials
+
+From the bridge detail page (**Settings** > **Bridges** > your bridge > **Credentials**):
+
+- **Rotate credential** — issues a new client ID and secret. The old credential stays valid until you explicitly revoke it. Update `bridge.yaml` with the new credentials, restart `bridge-client`, then revoke the old credential.
+- **Revoke credential** — invalidates the credential immediately and disconnects any running agent that uses it.

product/release-notes.mdx

@@ -6,7 +6,17 @@
 rss: true
 sidebarTitle: Release notes
 ---
-{/* Editor Refresh: 2026-06-23 */}
+{/* Editor Refresh: 2026-06-25 */}
+
+<Update label="Private bridge for MCP servers">
+
+### Connect private MCP servers through a bridge
+
+If your MCP servers run in a private network — on-prem, in an air-gapped cluster, or behind a firewall — you can now govern their tools through C1 without opening inbound firewall rules or exposing them to the public internet. A lightweight bridge agent (`bridge-client`) runs next to your server and maintains an outbound connection to C1; from there, tool access is requested, approved, reviewed, and audited exactly like any other entitlement in C1.
+
+AI access management must be enabled for your tenant. See [Connect a private MCP server through a bridge](/product/admin/mcp-server/mcp-bridge) for setup instructions, and contact the C1 support team if you'd like to try it out.
+
+</Update>
 
 <Update label="June 26, 2026">
 
@@ -864,7 +874,7 @@
 
 * **Reviewer performance:** Track reviewer decision rates and average review time. See who's holding up the queue and remind them to finish their reviews.
 * **Progress by app:** Gain clarity by precisely tracking review completion status broken down by application.
 * **Workflow visualization:** A campaign burndown chart lets you visualize the campaign's remaining open reviews over time.
 
 You'll find the updated dashboard on every running and completed campaign.
 
@@ -888,7 +898,7 @@
 
 C1 now supports custom user avatars! To change your own user avatar, open your profile menu in the upper right corner of the screen, click your name, then click the edit icon on your current avatar image. 
 
 Not content just updating your own avatar? On on the user details pages, managers can also upload avatars for their direct reports, and Super Admins can upload avatars for any user.  
 
 ### New bulk actions 
 
@@ -916,7 +926,7 @@
 
 * To make it easier for users to understand exactly what they're reviewing in a campaign, the by-user reviews view now shows the exact entitlement under review instead of the parent resource. 
 
 * We've consolidated entitlement provisioning and deprovisioning settings into a single new **Access management** section on an entitlement's details page. 
 
 * When clicking to the next or previous page of a table, the view now automatically scrolls to the top, improving the navigation experience.
 
@@ -956,13 +966,13 @@
 
 * We've added a new query to the **Access explorer** page: **Active external accounts**. This list can be downloaded as a CSV for easy sharing and analysis.
 
 * You can now create fine-grained revoke entitlement steps in your automations. Use criteria such as the entitlement risk level or compliance framework to zero in on which entitlements to revoke or to exclude from revocation. 
 
 * The task report you can generate and download on the **Task log** page now includes details on who approved each task and the approver's email address, making it easier to track and audit approval workflows.
 
 * When creating [attribute mappings](/product/admin/attributes) in the new directory UI, you can use a mix of direct mappings and CEL expressions for each source. This allows you to set up complex fallback logic, which is especially useful for attributes that accept multiple values, such as Additional Usernames.
 
 * You can now configure the deprovisioning process to be used for an entitlement on the entitlement's details page, providing more granular control over resource clean-up. 
 
 * The Microsoft Teams app now sends notifications to the relevant admins when a connector experiences a sync error or detects an anomaly in the synced data.
 
@@ -1026,7 +1036,7 @@
 
 ### Usability updates 
 
 * You can now require that a different user approves each step in request and review policies. Enable **Require distinct approvers** on a step to prevent users who approved previous steps from approving the current one.  For full details, visit the docs on [Policies](/product/admin/policies). 
 
 * Need a report of all the access granted to a certain application account? You can now create and download one by navigating to **Requests** > **Accounts** > **View access** and clicking the **Generate CSV** button. 
 
@@ -1095,7 +1105,7 @@
 
 ### Fixed! 
 
 * We fixed issues that were preventing users with either the **Connector Administrator** user role or both the **Read-Only Admin** and **Basic User** user roles from completing their assigned tasks. 
 </Update>
 <Update label="October 3, 2025">
 
@@ -1121,7 +1131,7 @@
 
 ### Fixed! 
 
 * When a limited-duration grant has expired, it is now shown on the user's **App catalog** page as requestable, rather than granted. 
 </Update>
 <Update label="September 19, 2025">
 
@@ -1179,13 +1189,13 @@
 
 ### Fixed! 
 
 * We fixed the names of the bulk actions used for marking multiple grants deprovisioned. 
 </Update>
 <Update label="August 29, 2025">
 
 ### System management controls
 
 On the new **System management** page in the **Settings** section, we've added controls that allow Super Admins to disable all Slack and email notifications, access profile membership automations, and automations for your C1 tenant. 
 
 Use one or all of these controls when a temporary pause in regular C1 operations is necessary for testing, to prevent unintended consequences, or to perform critical maintenance. Check out [Temporarily disable system features](/product/admin/global-settings#temporarily-disable-system-features) for all the details. 
 
@@ -1203,7 +1213,7 @@
 
 ### Request forms 
 
 If you need requestors to answer questions or provide additional information when requesting certain entitlements, you can now create custom request forms that gather this data. Build request forms to gather precisely the information you need, and set them on one or many entitlements. Check out [Collect additional information from requestors using request forms](/product/admin/customize-requests#collect-additional-information-from-requestors-using-request-forms) to learn more and get started. 
 
 ### Automations updates 
 
@@ -1227,7 +1237,7 @@
 
 * Good news for anyone heading out on vacation this month: When [setting your own out-of-office delegate](/product/admin/delegate#set-your-own-delegate) you can now select a **Permanent** (ongoing) delegate or a **Temporary** delegate with specified start and end dates for the delegation period. 
 
 * Assigned access request approvers and users with the **Super Admin** user role can now change the duration of a requested grant before approving the request. The change in duration will be noted in the task's audit log. 
 
   <Frame>
   <img src="/images/product/assets/release-notes-15-aug-25.png" alt="A screenshot of a request task in the C1 UI, showing the duration field in its active edit state."/>
@@ -1289,11 +1299,11 @@
 
 We're in the process of upgrading our older connectors from [v1 to v2](/baton/migration) to improve performance and enable long-term support. While your existing v1 connectors might be marked as deprecated, they are still supported. No action is needed at this time unless you encounter a non-critical issue, in which case we may guide you to migrate. 
 
 ### Unused access automations
 
 The new **Unused access** section on each app's details page lets you see and manage app accounts that have not been used recently, and that might be good candidates for revocation. Click **Account unused > 30 days** to view the list of accounts in that state. 
 
 You can also set up tailored unused access automations from this section to notify, revoke, or perform the actions of your choice when access is not used within a specified timeframe. Go to [Unused access automations](/product/admin/automations#unused-access-automations) to learn more. 
 
 ### Usability updates 
 
@@ -1315,7 +1325,7 @@
 
 * The edit button for an application's description is now visible even when the description is extremely long. 
 
 * When automatically deprovisioning an account, all steps in the policy are performed. 
 
 * Clicking **Next user** in a by-user campaign correctly loads the next set of reviews.
 </Update>
@@ -1325,11 +1335,11 @@
 
 * We've added a new automation step option: **Grant entitlements**. Use an automation to grant a user one or more entitlements when the automation's conditions are met. 
 
 * App-specific automations can be created and managed by application owners who also have the **App Admin** user role. You can create, view, and manage these automations on the application page's **Automations** tab. Go to [App-specific automations](/product/admin/automations#app-specific-automations) to learn more. 
 
 ### Usability improvements
 
 * On the **Applications** page's **Unmanaged apps** tab, we've made two key improvements: 
 
   * Use the new **Parent app** filter to show only the child apps of a particular IdP, SSO, or federation provider. 
 
@@ -1339,19 +1349,19 @@
 </Update>
 <Update label="July 11, 2025">
 
 ### Introducing automations 
 
 We're thrilled to introduce [automations](/product/admin/automations), a powerful new feature designed to dramatically streamline your operational processes within C1. Build custom workflows to handle repetitive tasks, reduce manual effort, improve compliance, and achieve greater efficiency. 
 
 Automations are ideal for:
 
 * Kicking off critical processes based on employee status changes
 * Providing seamless onboarding experiences
 * Ensuring secure and efficient offboarding
 * Managing role transfers with ease
 * Automating timely access reviews
 
 Explore these new capabilities on the **Automations** page!
 
 ### Inventory page 
 
@@ -1375,9 +1385,9 @@
 
 * When you replace a file, you'll now see information on the name of the previously uploaded file and the date when it was uploaded.  
 
 ### camelCase CEL expressions
 
 We are adopting camelCase for all [CEL expressions](/product/admin/expressions), and moving away from snake_case. This change will make writing and reading CEL expressions in C1 more consistent, and is intended to improve the overall developer experience. You don't need to modify any expressions you're using today, but new expressions should be written in camelCase. 
 </Update>
 <Update label="June 27, 2025">
 
@@ -1395,9 +1405,9 @@
 </Update>
 <Update label="June 20, 2025">
 
 ### App account deprovisioning
 
 By default, C1 automatically sets the account deprovisioning process based on your app's provisioning configuration. To customize deprovisioning, go to the app's **Controls** tab and [set how app accounts are deprovisioned](/product/admin/access-requests#set-how-app-accounts-are-deprovisioned).
 
 ### Usability improvements
 
@@ -1439,7 +1449,7 @@
 
 ### Streamline access request configuration
 
 The new [standard audience](/product/admin/access-requests#set-the-standard-audience-for-an-app-and-select-requestable-entitlements) setting on an application lets Application Admins and Super Admins quickly make specific entitlements within the application requestable to everyone in your organization or to select groups, without the need to set up an access profile. 
 
 ### Usability improvements
 
@@ -1457,7 +1467,7 @@
 
 ### Fixed!
 
 * The names of unmanaged apps are now automatically updated when the corresponding apps' names change in the IdP. 
 
 * Deleted access profiles are no longer included in the access summaries shown on an app's **Entitlements** tab. 
 
@@ -1482,7 +1492,7 @@
 
 * The full list of an app's linked entitlements is shown, instead of only the first 50. 
 
 * You can now successfully delete steps in an account provisioning or deprovisioning configuration. 
 
 </Update>
 <Update label="May 23, 2025">
@@ -1519,9 +1529,9 @@
 
 ### Usability improvements 
 
 * You can now set a SLA (service-level agreement) fallback step on a policy. If no action has been taken on a task step when the SLA timeframe you set elapses, the task can be automatically redirected to use a new policy or reassigned to a different user. 
 
 * On an application's **Entitlements** tab, access controls information is now shown in the **Requests** column, where you'll find a tooltip with info on which access profiles each entitlement is part of.
 
 ### Fixed! 
 
@@ -1546,11 +1556,11 @@
 
 * New this week: [Microsoft Azure DevOps](/baton/azure-devops) and [Workday Account (WQL)](/baton/workday-wql). 
 
 * The new [Zendesk v2](/baton/zendesk) connector adds support for syncing roles and provisioning roles, orgs, and groups. Learn more about [connector versions and migration](/baton/migration). 
 
 * You can now specify which [user attributes](/product/admin/attributes) a connector syncs to C1. Go to [Select which attributes a connector syncs](/baton/configure) to get started.
 
 * A new configuration field on the [Snyk](/baton/snyk) connector adds support for users who use regional hostnames other than `api.snyk.io`.  
 
 * We've added a configuration field to the [Okta AWS Federation](/baton/okta-aws-federation) connector that opts into the conversion of user assignments to direct assignments. 
 
@@ -1588,9 +1598,9 @@
 
 * The Greenhouse connector now supports account provisioning. You can also use the connector to revoke Site Admin user permissions from accounts. We've added a new configuration field to support this feature. Check out the [Greenhouse connector docs](/baton/greenhouse) to learn more.   
 
 * The Grafana connector now supports organization provisioning. 
 
 * The Asana connector now syncs licenses and supports license provisioning. We've added a new configuration field to support these capabilities. Check out the [Asana connector docs](/baton/asana) to learn more.   
 
 ### Usability improvements 
 
@@ -1634,13 +1644,13 @@
 
 * If a connector has failed three syncs following a successful sync, the connector owner (or the application owner if a connector owner is not set) will receive a email notification about the connector sync error. 
 
 * The Grafana connector now supports account provisioning. 
 
 * The Asana connector now supports account provisioning and has a new configuration option to add the ID of the workspace where newly created accounts should be added. 
 
 * The Incident.io connector now syncs basic and custom roles. 
 
 * To improve performance, the Okta-AWS Federation connector now requires that identities be pulled from an Okta connector. See the [Okta AWS Federation connector docs](/baton/okta-aws-federation) for more information. 
 
 ### Usability improvements 
 
@@ -1700,7 +1710,7 @@
 
 * **Last login** is now a default account attribute when [mapping data values from a file connector](/baton/file-connectors#map-data-values). For existing file connectors, refresh the connector's data to view and set this new mapping option. 
 
 * When setting up a policy that allows reassignment of tasks, you now have the option to limit which users a task can be reassigned to. Only the members of the reassignment allowlist will be available when a user reassigns a task.
 
 * You can now set a default access review view on a campaign or template. The default view setting (by app, by user, or unstructured) will open every reviewer's access reviews in the view you select, but reviewers can switch to a different view, if desired. 
 
@@ -1752,7 +1762,7 @@
 
 * The Workday connector now syncs security groups, and can be configured with a custom report in JSON format.  
 
 * You can now configure the Asana connector using a service account token. 
 
 * The AWS connector now syncs information on each account's last login. 
 
@@ -1798,7 +1808,7 @@
 
 ### Connectors 
 
 * The Jamf connector now syncs dynamic roles.  
 
 * The Google Cloud Platform connector now syncs organizations. 
 
@@ -1826,18 +1836,18 @@
 
 * New this week: [SAP SuccessFactors](/baton/successfactors), [Notion](/baton/notion), and [Jenkins](/baton/jenkins). 
 
 * The Tailscale connector now syncs roles, devices, and invites. 
 
 * The Dayforce connector now syncs roles and groups. 
 
 * The Google Workspace connector now syncs Google custom attributes.
 
 * These connectors received updates and fixes:
 
   * Azure Infrastructure (fixed sync errors when a mailbox fetch fails and errors when optional values were unset)
   * Entra ID (captures enterprise application usage)
   * Google BigQuery (fixed the cause of a sync error loop)
   * Okta (fixed errors that occurred when expected data was absent)
   * Workday (adds support for multiple roles in a custom report)
 
 ### Usability improvements 
@@ -1846,7 +1856,7 @@
 
 * You'll now find a **Created between** date range option when filtering tasks on the **Task log** page. 
 
 * Entitlement details are now shown in tooltips on the **Task log** page. 
 
 ### Fixed! 
 
@@ -1864,11 +1874,11 @@
 
 * New this week: [Redis](/baton/redis) and [Galileo Financial Technologies](/baton/galileo-ft).  
 
 * You can speed up the provisioning of Entra groups and roles by enabling the new **Schedule SCIM provisioning** option when configuring the Entra connector. This option forces a SCIM sync in Entra whenever new access is provisioned in C1. 
 
 * The Concur connector now supports role provisioning.  
 
 * The Litmos connector now supports course provisioning. 
 
 * The Azure Infrastructure connector now syncs storage accounts and storage account containers. 
 
@@ -1887,7 +1897,7 @@
 
 * To make it faster and easier to complete provisioning tasks, we've added the subject user's email address with a click-to copy button to the task assignment pane. 
 
 * Entitlement details are now shown in tooltips in tasks and when completing access reviews by app. 
 
 </Update>
 
@@ -1901,7 +1911,7 @@
 
 We're rolling out the ability to track usage data for key connected applications. Use this data to scope a UAR campaign to review grants that have gone unused lately.   
 
 * Opt into tracking Microsoft Entra usage data by enabling **Fetch user sign-in activity** on the Entra configuration page. 
 
 * The Okta v2 connector now collects usage data for Okta and the applications that Okta users SSO into. No configuration is needed.  
 
@@ -1917,10 +1927,10 @@
 
 * These connectors received updates and fixes:
 
   * Snyk (fixed an issue with provisioning organizations)
   * Zendesk (added additional error messages)
   * Snowflake v1 (fixed an issue with syncing users)
   * Databricks (fixed an issue with group provisioning)
   * Workday (added support for reporting user statuses)
 
 ### Usability improvements
@@ -1939,7 +1949,7 @@
 
 * Very large conditional expressions in policies can be successfully saved. 
 
 * Ownerless accounts are displayed correctly when reviewing campaign tasks by user. 
 
 * You can successfully duplicate any completed campaign. 
 
@@ -1957,7 +1967,7 @@
 
 ### Usability improvements
 
 * You can now mark tasks as provisioned or deprovisioned in bulk on the **Task log** page and your **Tasks** page.
 
 * We've added pagination to very long lists of entitlements on the **Manage access** page's **Browse** tab. 
 
@@ -1981,7 +1991,7 @@
 
 * These connectors received updates and fixes:
 
   * Okta
   * Google Workspace 
   * Azure Infrastructure 
 
@@ -1998,9 +2008,9 @@
 
 ### Connectors 
 
 * New this week: [Microsoft Azure Infrastructure](/baton/azure-infrastructure), [VictorOps](/baton/victorops) (aka Splunk On-Call).
 
 * When configuring the Microsoft Entra ID connector, you can now specify your Microsoft Graph API domain. 
 
 * These connectors received small updates and fixes:
 
@@ -2036,8 +2046,8 @@
 * These connectors received small updates and fixes: 
 
   * Salesforce (now only syncs accounts with a `UserType` value of `Standard`)
   * Databricks (fixed `failed to expand grant` error)
   * Coupa (fixed provisioned roles being deleted on the next sync)
   * Confluence (fixed group provisioning error)
 
 ### Usability improvements 
@@ -2056,17 +2066,17 @@
 
 <Update label="February 14, 2025">
 
 ### Automated unenrollment from access profiles  
 
 We're excited to launch automated unenrollment for access profiles, complementing our previously released enrollment functionality.  Now, when a user no longer meets the membership conditions of an access profile, C1 automatically initiates the unenrollment process you've configured.
 
 To learn more about unenrolling users, check out [Automate onboarding & offboarding access changes](/product/admin/dynamic-access-control).
 
 ### Connectors 
 
 * New this week: [PingFederate](/baton/pingfed).
 
 * The Asana connector now supports provisioning of teams and workspaces.
 
 * These connectors received small updates and fixes: 
 
@@ -2074,13 +2084,13 @@
   * Google Workspace 
   * Slack
   * GitHub
   * Databricks 
 
 ### Usability improvements 
 
 * We've added click-to-copy controls to the tooltips that show user and account information, making it easier to grab an email address or other info for use elsewhere. 
 
 * If you're a manager or have the Access Request Helpdesk, Access Request Admin, or Super Administrator user roles in C1, you can now request an access profile for another user on the **Request access** form. 
 
 ### Fixed!
 
@@ -2108,7 +2118,7 @@
 
 ### Connectors 
 
 * The Jira connector now supports syncing project roles. 
 
 * We made updates and fixes to these connectors: 
 
@@ -2118,7 +2128,7 @@
 
 * The by-app access review experience has been revamped. This sleek, streamlined new design features expandable info panels, bulk actions, and clearer indicators of your progress through your assigned access reviews.
 
 * When you click on a task number, a drawer now opens containing the tasks's details, next steps, related tasks, and audit log. Score one for team #no-more-modals.
 
 * You now have the option to scope a campaign by resource type within an app. This option is especially helpful when used in a campaign template, allowing you to automatically generate, for example, a quarterly review of all the teams in GitHub.   
 
@@ -2136,16 +2146,16 @@
 
 * We made updates and fixes to these connectors: 
 
   * Okta v2 
   * Workday
   * Salesforce
 
 ### Usability improvements
 
 * We've redesigned the tooltips that show user and account information to make them more relevant and helpful. 
 
   <Frame>
   <img src="/images/product/assets/release-notes-31-jan-25.png" alt="The tooltip on a user account showing the new design, which includes a summary of the account information and profile attributes."/>
   </Frame>
 
 * When setting up an access review campaign template, you can now include instructions that will be displayed to each reviewer in campaigns created from that template. 
@@ -2166,7 +2176,7 @@
 
 * When completing access reviews by user, you'll now see an icon if the user's last login to the app was more than 30 days ago. 
 
 * If a revocation task has errored, the task's outcome is now shown as "Revocation errored" on the campaign's **Access reviews** page and in the campaign report.
 
 ### Fixed! 
 
@@ -2212,7 +2222,7 @@
 
   * Snowflake v2 (fixed the connector's behavior when lists return no results)
   * AWS v2 (fixed sync failures when an SSO user's status could not be fetched)
   * Temporal Cloud (fixed issues with namespace permission grants and extraneous role grants)
 
 ### Usability improvements
 
@@ -2232,7 +2242,7 @@
 
 * You can now set up the Workday connector using either a custom report or an API client. 
 
 * The Databricks connector now includes the option to pass in the hostnames needed to configure the connector for use with Google Cloud Platform or Azure Databricks. 
 
 ### Usability improvements