Select Settings, then, under Account, open Integrations.
(Result: The pane opens on the tools a workspace can connect, grouped by what they are for: source control, project management, communication, monitoring, and the model provider behind the agents. A connected row reads “Connected” and names the account it was authorised as; an unconnected row carries a “Connect” button.) 1.Find the tool you are connecting, under its category.
(Result: Each row names the tool and what connecting it does in one line — “Sync repos, issues, and pull requests”, “Create and track issues from the terminal”. That line names the work the tool backs.) 1.Select Connect, and authorise Crusible as the account you want the workspace to act as.
(Result: Authorisation happens in the tool, as that tool's own account, and returns to the pane. The row then reads “Connected” and names the account.) 1.Open a channel that has that surface enabled, and select it in the surface switcher.
(Result: The surface now reads from the tool rather than from Crusible's own store, and the tool stays the record: work opened there appears here, and work opened here appears there under the account you authorised.) 1.Open the channel’s settings and read the Access rows: Agents may push to the branch, Agents may open pull requests, Agents may merge without a human and Agents may reach production. Which of them start on is in what agents can see and do .
(Result: Those four rows are what an agent may do with the connection you made. A connected provider does not widen them, and neither does connecting a second one.) - **If this doesn't work:**If Account does not appear in Settings, or Integrations is missing from it, your sign-in does not hold the permission that opens it: a pane you may not open is absent rather than shown and disabled, so ask whoever created the workspace to grant it. If the row returns from authorisation still reading its Connect button, the authorisation did not complete in the tool — start it again and finish it in the tool’s own window. If the row reads Connected but the surface shows nothing, check that the account you authorised can see the project, repository or workspace you expected on the tool’s side; a connection carries exactly the reach of the account behind it. If the surface is not in the channel’s switcher at all, it has not been enabled for that channel, which is in the channel’s own settings rather than here. If a step still does not match what you see, Troubleshooting is written for that moment.
One surface in the workspace is then backed by the tool your team already uses, and the row in **Integrations** is the record of it: the tool and the account it was authorised as. Everything else is unchanged — the conversation is still the spine of the work, and what agents may write is still the channel's own **Access** policy. - [Switch a surface's provider](https://crusible.dev/docs/admin/switch-a-surfaces-provider/) — How a surface comes to point at a connected tool instead of Crusible's own store, or back again, without touching the channel or its conversation.- [Every surface has a provider](https://crusible.dev/docs/concepts/every-surface-has-a-provider/) — Behind every surface is a provider that holds its data, and connecting a tool you already use changes one surface and nothing else in your workspace.