Credentials, bindings, and ownership
Three objects often get conflated. Keeping them straight is the difference between "IT sets this up" and "a builder can self-serve".
Audience: IT (the enabler) and builders
The three objects
- Integration. The provider definition in the platform's catalog (Slack, SharePoint, Stripe, and the others). Integration definitions ship with the platform and are not something your team creates.
- Credential. The artifact produced by completing setup for a specific integration: an OAuth token, a restricted API key, or similar. A credential belongs to whoever connected it, and the same integration can carry many credentials.
- Binding. The attachment of a credential to a specific Project. A binding is what makes the credential usable inside that Project. Builders create bindings.
How this plays out
- IT can pre-stage a credential for an admin-enabled OAuth integration once stage 1 is done. Builders bind that credential to their Projects without ever touching the OAuth dance.
- A builder can also create their own credential for the same integration, for example by OAuthing their own Gmail. They then bind their own credential to their Project.
- The two cases coexist. The same integration can have an IT-owned credential and several builder-owned credentials live at the same time.
See How connections get set up for the actor map across the three setup patterns.
Read the credential list
Open /integrations. The Connected tab lists every credential in the workspace and is the main credential surface today. Each row shows the provider, the credential's display name, the binding model, the syncing account, the realtime state, and last sync. Four stat tiles at the top scope the list to Total, Healthy, Needs attention, or Syncing now. The toolbar adds search by name, a provider filter, a state filter, and a realtime filter.
Click a row to open the detail Drawer. The Drawer header carries the title, the binding badges (Personal grant or Shared grant, with You sync this or Synced by another member where it applies), and the description. The Overview tab shows phase progress and the ownership line. The Configuration tab names the resources the credential is wired to (sites, folders, channels, look-back days, and similar). The History tab shows recent phase events. The Settings tab carries renaming, takeover, and disconnect.
Share a credential across Projects
A credential is a workspace-level artifact. The same credential can back many bindings, one per Project. Builders pick the credential from a list when they configure the integration inside a Project; admin-staged credentials appear in that list alongside personal ones.
The credential's binding model decides how sharing works:
- Subject-bound single grant (personal): the credential runs as the connecting user. Sharing across Projects is supported, but the integration pauses if the user loses access.
- Shared resource, multi-grant (team-shared): one credential, many bindings, with a designated syncer. SharePoint, Microsoft Teams, GitHub, Slack, OneDrive, and Drive use this model.
- Tenant service account: the credential is the workspace's own account, not tied to any user. Ramp, Stripe, and Exa use this model.
Reassign ownership when people change roles
For shared-resource credentials, the designated syncer is the user whose token drives the sync. When that person changes roles or leaves, transfer the role to another member.
Open the credential
On /integrations, click the row to open the detail Drawer.
Connect your own account, or pick another connected account
In the Configuration tab's credential picker, connect your own account or pick an existing connected account. The picker calls out that another member is currently the syncing user and lets you switch ownership.
Confirm the takeover
The previous syncer's token stays connected and can be reused later, but the active syncer is now the account you selected. The realtime indicator returns to its normal state once the first sync completes under the new owner.
For per-user (personal) credentials, the path is simpler: the new owner connects their own credential and the old binding is replaced. For tenant credentials, ownership lives with the workspace, so role changes do not require a transfer.
Audit the credential trail
Every credential mutation produces an audit entry. Open /audit and filter by the actor or the connections view to see:
- credential created, renamed, and disconnected,
- binding created and removed,
- sync ownership transferred,
- the realtime state transitions that follow.
The Engineer lens on the entry exposes the request payload and the before-and-after state. See Audit and evidence for the full ledger model.
Self-serve OAuth versus IT-pre-staged credentials
The setup pattern decides who creates the credential. Builders create their own for self-serve OAuth integrations like Linear. For admin-enabled OAuth integrations, IT can choose to pre-stage a credential after stage 1 so the binding step is the only thing builders touch, or leave that step to builders and let them connect their own accounts. For admin-only API key integrations (Ramp, Stripe, Exa), a functional admin generates and pastes the key once, and builders bind to that single credential. See How connections get set up for the actor map.
Credentials bind to Projects, not to teams. There is no team-level binding today. To make a credential available to a specific team (for example, "SharePoint for the AP team only"), pre-stage the credential and add it to the Projects that team's members work in. Membership on those Projects, combined with team membership, is the effective gate. A first-class team binding is a tracked product gap.