Teams and permissions
Admins and users, teams, who can use which shared connection, and what users may set up.
An organisation has two kinds of member. Admins (the owner included) can do everything: billing, members, teams, every shared resource. Users can use what is there, plus whatever the organisation's default and their teams allow. Teams are managed by admins on Dashboard → Organisation → Teams.
Roles
| Role | What they can do |
|---|---|
| Admin | Everything, always: manage members and teams, add and remove shared connections and keys, decide who can use each shared connection, control routing, manage billing. |
| User | Use the connections, keys and routing available to them. Anything more comes from the organisation default or a team. |
Admins change a member's role from the Members tab ("Make admin" / "Make user"). The owner is the admin who created the organisation and cannot be demoted there.
Teams
A team is a named group of members with two things attached:
- Permissions: what members of the team may set up (listed below).
- Shared connections: which of the organisation's team-restricted connections the team may use.
A user's effective permissions are the union of the organisation default and every team they are in. Teams only ever add; to make a team narrower than everyone else, lower the organisation default and grant the rest through teams. Admins in a team gain nothing from it.
Permissions
| Permission | Grants |
|---|---|
| Add personal connections | Connect systems that serve only their own requests. |
| Add shared connections | Connect systems for the organisation, choose who can use them, and remove the shared ones they created. |
| Add personal model keys | Use their own provider keys for their own requests. |
| Add shared model keys | Add provider keys everyone in the organisation can use. |
| Change their own routing | A personal ladder and agent settings that apply to their requests only. |
| Control organisation routing | The shared ladder, agent settings and the default model. |
| Create shared jobs | Schedule jobs that are visible to and manageable by the organisation. |
| View billing | See the subscription status, trial and next charge. Changing it stays with admins. |
| View organisation usage | Token usage by user, team and model for the whole organisation. Everyone can see their own. |
The organisation default ("Users in no team" on the Teams tab) is what a user has before any team grants more. Out of the box it allows the three personal permissions. Clear everything to make users only use what admins give them.
Who can use a shared connection
Every shared connection has an access setting, changed from its row on Connections under "Who can use it", or from a team's page:
- Everyone in the organisation: the default.
- Only these teams: admins and the ticked teams. A team with no restricted connections ticked, and an organisation default without the personal-connection permission, is a team that can only use what is open to everyone.
Access applies wherever the connection would be used: the dashboard Chat page, the API, jobs (which run as their owner), the MCP server and the OpenCode and Claude Code engines. A user who may not use a connection does not see it and the model is not given its tools.
Personal connections are unaffected: they belong to one person and serve only their requests.
Typical set-ups
- Support team: a team "Support" granted the Help Scout and warehouse connections, with "Add personal connections" so agents can connect their own mailbox. Finance connections stay restricted to a "Finance" team.
- Everyone reads, a few build: organisation default cleared; a "Builders" team with the shared-connection, shared-key and organisation-routing permissions.
- Contractors: no team, organisation default cleared. They can chat and use the open shared connections, nothing else.
API behaviour
Permissions and connection access follow the API key's owner: a key created by a user carries that user's teams and permissions, so an agent using it sees exactly what the person would. The memtro_schedule_job tool refuses a shared job for a user without the shared-jobs permission.