Credentials, bindings, and ownership

Three objects often get conflated. Keeping them straight shows who connects an integration and who can use it.

Audience: IT (the enabler), team admins, 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 new credential belongs to a team or to the whole workspace, 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

• A team admin connects a credential at Team scope, or a workspace admin connects one at Workspace scope. On the Integrations page, they choose the scope in Available to when they connect.
• A Team credential is available to members of that team and to every Project in the team. A Workspace credential is available to Projects across the workspace. Builders add it to their Projects without signing in to the provider.
• Builders cannot create new personal credentials, and new private Project attachments are rejected. Personal credentials that already exist keep working for their owners, and so do existing private attachments.

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

The same credential can back many bindings, one per Project. Builders pick the integration from the list in the Project context and select Add to project. The list shows the Team and Workspace integrations available to the Project. Being available does not add an integration to any Project automatically.

The credential's binding model decides how sharing works:

• Subject-bound single grant (personal): the credential runs as the connecting user. You cannot create new personal credentials, but existing ones keep working. 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.

For an existing personal credential, promote it to a team or the workspace before the owner leaves, so that admins manage it. See Promote a personal integration. 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 does the work before the credential exists. For self-serve OAuth integrations like Linear, a team admin or workspace admin connects the credential without IT. For admin-enabled OAuth integrations, IT does stage 1 once, and then a team admin or workspace admin connects the credential. For admin-only API key integrations (Ramp, Stripe, Exa), a functional admin generates the key and an admin pastes it once. In every pattern, builders bind to the credential and do not connect their own accounts. See How connections get set up for the actor map.

Promote a personal integration

You can make an existing integration available more widely without reconnecting it. The connected account, the selected content, and the sync state stay the same, and compatible Project attachments remain.

• The owner of a personal integration can promote it to Team or Workspace. They must be a team admin of the destination team or a workspace admin.
• A workspace admin can promote any Team integration to Workspace.
• You cannot narrow the scope again, and you cannot move an integration from one team to another.

After the change, admins of the team or workspace manage the integration, and their changes affect every Project that uses it. A promoted personal integration no longer appears in your Home. The change cannot be reversed in settings. If a Project outside the destination team uses the personal integration, the promotion to that team is blocked. The error names each such Project that you can read.