How connections get set up
Not every integration is set up the same way. Three patterns cover all of them.
Audience: IT (the enabler), team admins, and builders
The three stages
Stage 1: Organizational prerequisite. A one-time setup that has to exist before anyone in your org can connect. Could be a Microsoft Entra app registration, a Google Cloud project with OAuth client, a GitHub Workflow install, or a Slack workspace install. Not every integration has a stage 1.
Stage 2: Credential creation. The actual OAuth sign-in or API key paste. A team admin creates the integration for their team, or a workspace admin creates it for the whole workspace. For OAuth, the admin signs in once with the account the integration syncs as. For API keys, it is one paste by whoever holds the key. Builders cannot create new personal integrations.
Stage 3: Project binding. Adding an existing integration to a Project so the agent can use it. Always done by the builder. A Team integration is available to Projects in that team, and a Workspace integration is available to Projects across the workspace.
The four actors
- IT. Owns enterprise identity, Microsoft and Google Cloud admin consoles, and platform governance.
- Functional admin. Holds Ramp and Stripe admin access, sometimes Slack workspace admin. Often a Finance leader, not IT.
- Team admin or workspace admin. Creates integrations at stage 2 and decides whether each one is available to a team or the whole workspace.
- Builder. Anyone authoring Projects and Workflows.
The three setup patterns
Self-serve OAuth
No stage 1. The platform owns the OAuth application on its side. A team admin or workspace admin signs in once and is done.
Examples: Linear.
Admin-enabled OAuth
Stage 1 is IT. Stage 2 is a team admin or workspace admin.
Examples: SharePoint, Microsoft Teams, OneDrive, Outlook (mail and calendar), Google Drive, Gmail, Google Calendar, GitHub, Slack.
The non-obvious part of admin-enabled OAuth: once stage 1 is done, team admins connect integrations for their own teams without IT. The org-level work is a foundation, not a permanent gate.
Admin-only API key
No per-user OAuth. A functional admin (usually Finance) generates a restricted API key and pastes it. Builders bind to that single credential.
Examples: Ramp, Stripe, Exa.
What this means for you
If you are IT, your work concentrates at stage 1. Once stage 1 is done for an admin-enabled OAuth provider, you can step back and let team admins connect integrations for their teams.
If you are a functional admin, you own stage 2 for admin-only API key providers.
If you are a team admin or workspace admin, you do stage 2 for OAuth providers. You choose Team or Workspace in Available to when you connect.
If you are a builder, you do stage 3. You add the Team and Workspace integrations available to your Project without signing in to the provider. Ask a team admin when the integration you need is not available yet.
Each per-provider setup page begins with a "Who connects this" block that names the actor for each stage and the artifact each stage produces.