Teams, organizations and access
These pages are about who works with you, and what each of them may do. An organization is a group of people who own things together. A team is a list of people inside a workspace, so that you can give access to all of them at once. A workspace role says what a member may do in each part of the workspace, and grants and item access narrow that further, down to one bucket or one item.
Teams opens from the Teams row in the rail. Roles are given out from Members, on an organization's workspace.
Topics
- Teams: a named set of members, for giving several people access at once.
- Organizations: shared ownership, and how an organization is created and archived.
- Members: an organization's roster and the role each person holds.
- Workspace roles: the roles a member can hold, from viewer to owner.
- Groups and grants: permission on one bucket, one kind of bucket, or one row.
- Item access: hiding a single item from everyone but the people you name.
- Team reach: letting a team work inside one of your products.
What you do with teams and access on the site, a program can do over the API: make teams, edit rosters, define roles and assign them, read what a member may do, restrict items, and give a team reach into a product.
Teams are plain resources under the team tag, with list, create, read, update and delete. The roster has calls of its own to list a team's members, add one and remove one.
Roles and access are the access routes. One family holds the roles, one the assignments, and one returns what you may do in each area once your roles are combined. Another lists the feature areas themselves. Item restrictions are set and cleared by a restrict call and a restore call, and team reach is read and granted under the same tag.
Over MCP, the teams tool group lets an agent list a team's members, add one and remove one. Whether the agent may edit a roster is decided by the same rule as on the site.
The full list of routes, with each one's parameters, body and responses, is the REST reference on the help site. The tools an agent gets are listed in the MCP reference.
Teams never own anything. Owners are people and organizations. Keeping teams out of ownership means the chain of ownership has one shape, and a team's workspace needs no ecosystem of its own.
What you cannot read is not found. A member without read on an area learns nothing about whether the area has anything in it. The same rule that hides a private persona hides a feature you cannot read.
A role only adds. What you may do is the sum of your roles, so a role can be understood by reading it, and adding a role never takes anything away.
The last admin is protected. A workspace cannot be left with nobody to run it by its own members.
The list of areas is checked at start-up. The feature areas are a list kept by hand, and the backend refuses to start if one is missing, because a hand-kept list drifts silently and a permissions table with a hole in it lets things through.
One rule, every surface. The one answer to "may this person edit this roster" is used by the site and by an agent's tools alike.