Connections

The connector catalog — what each connection reads, which ones need an admin account, how Okta's own-app setup works, and how Alchex shows a connection is actually working.

Connections let Alchex read evidence from the systems your organization already uses — your document stores, identity provider, ticketing, code hosting, and monitoring tools. Every connection is read-only by construction: Alchex requests read-only permissions wherever the vendor offers them, enforces read-only calls in its own code where the vendor doesn't, and refuses at build time to ship a connector that could write. Nothing Alchex does ever changes data in a connected system.

Connections live in Settings → Connections. Only a workspace Owner or Admin can connect, test, or remove one.

The catalog, by category

Available connectors are grouped by the kind of evidence they collect, in the order most workspaces should connect them — identity and documents unlock the most, so they lead.

Identity & Access

Who has access to your systems, and what administrators changed. Connect one of these first.

Okta — run an access review against your Okta org. Alongside listing users and groups, Alchex can show who is in a group, and for one person: the groups they belong to, the applications they can open (granted to them directly and inherited through a group), the third-party OAuth clients holding access in their name, and the devices they have enrolled. The System Log answers newest-first and takes a date range — without one Okta returns the last seven days only, and the answer says so. Advanced setup (see below).
Microsoft Entra ID — users, groups, sign-ins, and directory audit logs. Admin account required: the account you connect with needs the relevant admin or reader role, or these endpoints return nothing.
Google Workspace — run an access review against your directory. Alongside listing users and groups, Alchex can show who is in a group — including people who reach it through a nested group, which Google leaves out unless asked — the groups one person belongs to, and a single user's record with their admin, suspension, archive and 2-step-verification state. Admin and login audit activity takes a date range; without one Google returns the most recent 180 days only, and the answer says so. Admin account required: connect with a Workspace admin account.

Documents & Knowledge

Your policies, procedures, and records — the documents your reviews cite.

Google Drive — find and read Drive files. Evidence: a file, or a folder's contents. In the evidence picker a Drive folder opens — step into it and pick the file inside, or use the folder itself. A typed search phrase is never evidence: the field's search finds the real file, and that file is what gets pinned.
SharePoint & OneDrive — search and read documents in your Microsoft tenant, and inspect what surrounds them. Alongside search and read, Alchex can list a site's document libraries and walk their folders, read a SharePoint List (registers and inventories kept as lists rather than files), show a document's version history, and show who has access to a file — direct grants, sharing links, invitations, and access inherited from a parent folder. Evidence: a file, found with the field's search or by its item id — never the search phrase itself.

About the access list: Microsoft returns the sharing permissions visible to the connected account. If that account does not own the file, it may only see the permissions that apply to itself — so a short list is not proof that nobody else has access. Alchex says so alongside every result rather than presenting the list as complete. Connect with an account that owns the material you intend to review.

All of this is read-only, and it uses the permissions the connection already has — nothing changes for connections made before this, and nobody is asked to reconnect.
Box — search and read files and folders. Evidence: a file, a folder's contents, or a shared link. A Box folder opens in the evidence picker the same way Drive's does.
Dropbox — inventory Dropbox content and run an access review over it. Alongside browsing and search, Alchex can show who can reach a file or folder — people, groups and pending invitees, including access inherited from a parent folder — and which shared links exist, with the audience each one exposes. Evidence: a file, or a folder's contents. Read-only: Alchex never creates, moves, or deletes anything in Dropbox.

What you approve when you connect: Dropbox's consent screen asks for three read permissions and nothing else — your basic account information, file and folder information (names, paths, sizes and revisions, not file contents), and your sharing settings and collaborators. There is no write permission in the list, so the connection cannot change a file, a folder, or a share even if asked to.
Notion — search and read workspace pages, now through Notion's own hosted connector service. Evidence: a page or database — paste its link or id — and the workspace user list. (Evidence authoring returned 2026-08-25, reconciled to the service's verified abilities.)
Confluence — search and read pages in your Confluence spaces, now through Atlassian's own hosted connector service. Evidence: a page (paste its link, or give your site plus the page id), a space's page list, or your space list — each addressed by your site (for example acme.atlassian.net). The same organization-administrator setting as Jira applies.

What a Dropbox access review does and does not cover. Shared links are listed as the connected account owns them — a link another member created for the same file is not visible to this connection, so treat the list as a lower bound on external exposure rather than the complete picture. Member lists include people who inherit access from a parent folder, and a group appears as a single row even though everyone inside it holds the access it grants. Dropbox's search runs on an index that catches up after a change, so a just-added file can be missing from a search that finds everything else — Alchex says so in the answer rather than letting an empty result read as proof that nothing is there.

Not every connected system can produce evidence yet. Gmail cannot: writing a fetch means naming the exact call and the exact details it needs, and for Gmail those details are not yet known here — so rather than guess at a mailbox, the record says so and asks you to pick another source. The evidence page always tells you which case you are in.

Tickets & Projects

Change-management and incident trails.

Jira — issues and projects, now through Atlassian's own hosted connector service. Evidence: an issue (paste its link, or give your site plus the issue key) and the visible-projects list, each addressed by your site (for example acme.atlassian.net). Audit-log evidence does not return: Atlassian's service offers no audit-records read, so that older evidence shape asks you to pick a different source. Your Atlassian organization's administrator controls which AI tools may connect (Administration → AI settings); if a connection is refused there, that setting — not Alchex — is the door to open.
Asana — the work itself, and what happened to it. Projects and tasks with their assignee, section, due date, completion and custom-field values, who is in a team, and a task's activity stream: assignment changes, completions, section moves, comments and field edits, each with an actor and a timestamp. Evidence: a project, a task, or a task's activity. Read-only: Alchex never creates, edits, completes, or deletes anything in Asana.

What you approve when you connect: Asana's consent screen asks for seven read permissions and nothing else — projects, tasks, task activity and comments, teams, team memberships, users, and workspaces. There is no write or delete permission in the list, so the connection cannot change or remove anything in your workspace even if asked to.

Two limits worth knowing. Task search is an Asana Premium feature; on a free workspace Asana refuses it, and Alchex says that is a plan limit rather than letting it read as a broken connection. And an activity stream is what Asana chose to record and keeps under your workspace's retention — an absent entry is not proof the action did not happen, which is the difference between an activity stream and an audit log.
Linear — issues and projects, now through Linear's own hosted connector service. Evidence: an issue (paste its link or key), a project, and the team, member, document and comment lists. (Evidence authoring returned 2026-08-25, reconciled to the service's verified abilities.)

Jira and Confluence are separate cards; connecting either asks only for that product's read permissions on Atlassian's consent screen. Workspaces that connected the older combined Atlassian (Jira + Confluence) card before the split keep their connection listed; reconnecting it goes through Atlassian's hosted connector service like the product cards, and it no longer appears for new connections.

Code & Change

GitHub — organization members, teams, and the org audit log.
GitLab — connected through GitLab's own hosted connector service. Evidence: a merge request, pasted by its link. Group, membership and audit-event evidence does not return: GitLab's service reads issues, merge requests and pipelines only, so those older evidence shapes ask you to pick a different source.

Monitoring & Security

Sentry — issues and projects from your Sentry organization, now through Sentry's own hosted connector service. Evidence: an issue (paste its link, or give the organization slug plus the issue id), and the organization, project and release lists. Reconnecting an existing Sentry connection asks for a fresh consent — the old installation-based link is retired.

Communication & Business

Slack — channels, workspace members, and messages you can search, now through Slack's own hosted connector service. Reconnecting asks for your own read permissions alongside the workspace's — both on Slack's consent screen. Evidence: a channel's member list and a member's profile. Whole-workspace channel and member lists do not return: Slack's service answers name searches, not full listings, so those older evidence shapes ask you to pick a different source.
Salesforce — records and object metadata, now through Salesforce's own hosted connector service. Advanced setup: like Okta, Salesforce connects through an app your own org registers — an External Client App, a one-time setup of about five minutes that the connect dialog walks you through (create the app, set its callback URL, grant the listed scopes, activate the read-only records server, then paste the My Domain URL and consumer key). Two waits are normal and are Salesforce's, not ours: a newly created External Client App can take up to 30 minutes to start accepting sign-ins, and a newly activated server up to two minutes — if the first Connect attempt is refused right after setup, wait and try again rather than changing anything. Sandbox orgs also paste their own server URL from the org's setup page. Evidence: an object's schema, the queryable-object index, an object's recent records, and the connected user. A single record by id or lightning link does not return: the service offers no record-by-id read, so those older evidence shapes ask you to pick a different source.
Gmail — search and read messages in the connected mailbox. Limited availability: Google classifies mail access as a restricted permission and requires an independent security assessment before an app may offer it broadly, so Gmail currently connects only for accounts we have registered for testing. Ask us to add yours.

Connecting

Every connector connects the same way: click Connect, approve the consent screen in the popup, and the connection appears under Connected. Several connectors now run through the vendor's own hosted connector service behind that same button — the only visible difference is whose consent screen appears, and for some vendors the sign-in registers Alchex automatically instead of using a pre-registered app. The account you approve with is the account whose access Alchex inherits — for the two admin account required connectors above, that means connecting with an admin account, or the connection will look healthy but return no directory or audit data.

There is no connector that asks you to paste an API key. Access is always something you grant on the vendor's own consent screen and can withdraw there, which means you can see exactly what Alchex was given and revoke it without going through us.

If your plan meters connections, only completed connections count — an abandoned consent popup never uses up a slot.

Renaming a connection

A connection's name is yours to change. Open it from the list and use Rename beside the title — type the new name and press Save or Enter, or Escape to leave it alone. This is a display name only: it renames nothing in the vendor's system, breaks no label or reference pointing through the connection, and takes effect everywhere the connection is listed. Useful when you connect the same product twice — Drive (Finance) and Drive (Engineering) read better than two rows called Google Drive.

Only an Owner or Admin sees Rename, for the same reason only they can connect or remove: the change is workspace-wide. A member viewing the page sees the name, without an edit control that would refuse them.

Finding a connection in the list

Every connection is listed under the product's own name — the same name it carries in the catalog above. The search box at the top of Connections matches on that name, so typing part of a product name narrows the list to it.

If you have previously seen connections listed as Custom MCP server, or found that searching for a product name returned nothing even though the connection was there, that affected connectors added most recently and is fixed. Their names and search now behave like every other connector's. No action is needed on your side — reopen Settings → Connections and the correct names appear.

Okta: bring your own app (advanced setup)

Okta has no central sign-in service Alchex can register one app with, so each organization connects through an OAuth app it creates in its own Okta admin console — a one-time setup of about five minutes. The connect dialog walks you through it:

In the Okta admin console, open Applications → Create App Integration and choose OIDC — Web Application.
Set the app's sign-in redirect URI to the value shown in the dialog (copy it from there).
On the app's Okta API Scopes tab, grant the read-only scopes the dialog lists.
Paste your org URL and the app's Client ID and Client Secret into the dialog and connect.

Both standard Okta domains (your-org.okta.com) and custom domains (login.your-company.com) work. Custom domains are verified server-side before they're accepted: the domain must resolve publicly and answer as a real OIDC org.

Re-authorizing an existing Okta connection is safe at any point — if you close the consent popup partway through, the previous working connection stays intact.

Every ability listed for Okta above works with the read-only scopes in that one-time setup. Nothing here asks for more, so a connection made before these abilities existed gains them without being reconnected.

Long lists say when they are partial. Okta returns large results a page at a time, so a group with hundreds of members comes back in pages. Alchex marks a partial answer as partial and continues from where it stopped — a page of fifty is never presented as the whole group, because on an access review the person who would be missing is exactly the one you needed to see.

Trusting what you see

The panel is designed so a broken connection can't hide behind a green dot:

Verified, with a time. Each connected row shows when its last real health check ran — "Verified 2h ago" means Alchex made an authenticated round-trip to the vendor and it worked, not merely that a token exists.
Automatic re-checks. Opening the panel silently re-probes connections whose last check is stale; a dead credential flips to Needs reconnecting instead of sitting green for days.
Test on demand. The test button on each row runs the same authenticated probe and reports healthy, needs-reconnect, or couldn't-verify — a momentary blip is never shown as a confident result either way. For a connection served through a vendor's own hosted connector service, the same test also checks that every ability Alchex expects is still offered by the vendor, and a healthy result names any that are missing rather than letting them fail silently later. On a connection's own page the answer is written under the buttons and stays there: one sentence naming the connection and what to do next, with Reconnect offered right in it when that is the fix. (It used to be a message that appeared briefly and could be missed entirely, which made pressing Test feel like it did nothing.) The reason a vendor gave is never shown raw — you get the sentence, not the error code.
New capabilities banner. When Alchex adds abilities to a connector that need permissions your original consent didn't include, the row says so and one reconnect enables them. Where no new permission is needed, new abilities simply appear.

Labels: naming what a connection reads

A connection is the door; a label is a name for one specific thing behind it — a folder of signed policies, a saved list of open incidents, an access-review sheet. A document or control that cites connected data cites the label, never the underlying file or query. That indirection is the point: when the source moves, you re-aim the label once and everything citing it keeps working, unchanged.

A label is a citation pointer, not evidence. The thing that carries proof is an evidence record — a card of its own with a statement, an optional source and an append-only run history. Both carry an EVD- code numbered under the owning team, drawn from one sequence, so no two of them can ever be handed the same identifier. Pasting a link on the Evidence page (or connecting a resource from a reference dialog's Connect door) mints a record directly against the connection; no label is involved, and no label ever turns into one.

Labels are no longer created or managed anywhere in Alchex. The one screen that offered it — the reference dialog's Connected systems section — was replaced by an Evidence section, because an evidence record does everything a label did and is the thing an audit can actually grade. See References.

Labels you already have are untouched and keep working: documents that cite one still resolve it, control agents still read through it, and nothing you have written has changed. What is gone is the ability to make a new one, rename it, re-point it or remove it.

To point at something in a connected system now, make an evidence record. Create it from Governance → New → Evidence and give it its source on the record's own page: the record — not a label — is what carries the statement, the source and the run history. (A reference dialog used to carry a Connect a resource door that did this from inside a document; it was withdrawn on 2026-08-12, so records are made in one place and cited from another.)

Settings continues to own the connection itself: test it, reconnect it, disconnect it, remove it, rename it.

A label belongs to a team

The connection is workspace-wide; the labels on it are not. Every team sees the same connections — that has not changed. A label, though, is owned by a team, and you are shown only the labels of the teams you can reach: your own teams, and — for a workspace Owner or Admin, who reach every team here as everywhere else — all of them.

This still governs what an existing label will resolve to for a given reader: a label owned by a team outside your reach answers exactly as one that never existed — not found. The two cases are deliberately identical, because an address is never a way to discover that another team's label exists. Labels that already existed were assigned to the team of whoever created them, so nothing lost its home. See Workspaces and teams.

Removing a connection

Remove a connection from its Configure page. Removal deletes the stored credentials immediately. Revoking Alchex's access from the vendor's side (for example, from your identity provider's app list) has the same effect — the next health check flags the connection as needing attention.