See the complete route index at https://crusible.dev/llms.txt before following links. # Roles and permissions The workspace roles the product shows, the channel-level Access rows, and which of the two decides what. Permission in Crusible is held in two places, and they answer different questions. A workspace role decides what a person may reach across the whole workspace. A channel's **Access** policy decides what happens inside one channel, for people and for agents alike. ## The workspace roles A person's role is a value in the **Access** column of **Directory**, under **Account** in Settings, and it takes one of four: **Owner**, **Admin**, **Member** and **Guest**. An invitation that has been sent and not accepted carries the role it was offered in the same column. One **Access** row in a channel names an actor the role list does not: **External members see the repo** decides whether an external member, who arrives through a bridge or a partner organisation, sees the repositories that channel has mounted. ## What the Account group holds, and what opens it **Account** in Settings holds the workspace's own configuration — **Directory**, **Providers**, **SSO**, **Connections**, **Credits and billing** and **Integrations**. Each of those sections is reached by its own permission rather than by one role, and a section you may not open is absent from the list rather than shown and disabled. The sections you can see are therefore the ones you hold, and a colleague seeing fewer than you holds fewer — the list itself does not say which are missing. **SSO** is the narrowest of the six: its own description reads “Enterprise single sign-on, owner only”. No screen enumerates a full role-by-permission matrix, and this page does not supply one. What the product states is what is above: a role is a value in **Directory**, each **Account** section is gated on its own, and a channel decides its own **Access** rows. ## A channel's Access policy The **Access** group in a channel's settings pane carries eight rows. | Access row | Who sets it | What it decides | | ---------------------------------- | --------------------- | --------------------------------------------- | | Visibility | An admin, per channel | Who can find and open the channel | | Who can post | An admin, per channel | Which members may post in it | | Agents may push to the branch | An admin, per channel | Whether agents commit to the channel's branch | | Agents may open pull requests | An admin, per channel | Whether agents open pull requests | | Agents may merge without a human | An admin, per channel | Whether a merge lands with no human approval | | Agents may reach production | An admin, per channel | Whether agent work reaches production | | External members see the repo | An admin, per channel | Whether an external member sees mounted repos | | **Notify me about** | Each member, for self | Which messages in the channel notify them | The group sits in one scrolling settings pane, alongside the channel's members, its signal dial, its per-agent message volume, its enabled surfaces and its archive control. **Visibility** carries a value such as **Workspace**, **Who can post** carries one such as **Members**, **Notify me about** carries one such as **Mentions**, and the four agent rows are toggles. ## Which of the two decides what A role travels with a person across the workspace. An **Access** row does not travel at all: it is set on one channel, and a channel with different work in it carries different rows. The same agent, in two channels, may open pull requests in one and not the other. Two of the agent rows are ordinary working permissions, and a Feature delivery channel starts with them on. The two that remove a person from the loop are **Agents may merge without a human** and **Agents may reach production**, and widening either is a choice somebody makes rather than a setting nobody noticed. For merge, the Feature delivery template states its starting position in the channel wizard: “Lens blocks the merge until a human approves”. For production, no screen and no product string fixes a starting position, so read the row in the channel you are in rather than assuming one. ## Where a permission change is recorded The channel's settings pane is the current state. The conversation is the record of the decision behind it: a message that settles something carries a **Decision** tag beside its timestamp. An agent's own profile carries the record of what it has been assigned, and a session replay carries every command that shell ran. **Planned.** The pane that holds your own replays, **My history**, opens on a disabled **Coming soon** control today. See [Settings](/docs/admin/settings/) for what it is designed to hold.