Connection scope

Every integration connection is placed at one scope, which decides who can use it. A connection shared into a project or an organization is one credential the whole group's agents can act on; a user connection is private to the person who made it.

Which scopes a deployment offers

The ladder comes from two feature flags, read server-side, so a level a buyer turned off never appears in any picker.

project needs only the projects feature, because it partitions rather than shares: in an SEO product each project is a different client site with its own connection, which is as useful to a solo user as to a team. user is the floor - every deployment can keep a credential to the person who connected it.

Visibility

What a caller sees is the union for the workspace they are in: the active project's connections, the active organization's shared ones, and their own. That same union is what the agents get, so a shared connection is a shared tool, sign-ins included.

• Losing context narrows, never widens. A request outside a project simply sees no project connections, never every project's.
• Scope is fixed at creation. To move a connection, disconnect and reconnect it.
• A connector who leaves takes their account with them. When a member leaves or is removed, every connection they made for that organization (shared with it or in its projects) has its credential wiped in the same request and reads Connected by someone who left. Any member can sign a sign-in back in and becomes its connector; a key needs an organization admin to replace it. Their personal connections and those in other organizations keep working. Every credential read also checks, when it is made, that the connector is still a member and can still reach the project, so a failed cleanup or a sign-in landing after the removal never reaches their account.
• maxInstances counts per scope context, so a cap of 1 allows one in each project, one shared with the organization, and one of the user's own. The count runs inside the write, so a double-click cannot slip a second past the cap.
• A shared sign-in serves every member. An oauth connection carries its scope through the authorization flow, and its request tool (any path on the provider, with the connector's token) runs in every chat and automation of anyone who can see it, exactly like a pasted key shared with the group. An owner who signs a data login in at organization scope sets it up once for the whole team; share a sign-in only as widely as its account should reach.

Restricting an entry with allowedScopes

A catalog entry can keep itself off the levels it does not belong on. ["user"] makes an entry private however the request is shaped; ["project"] files each connection under one project. The list is intersected with the deployment's ladder, so it narrows and never widens.