Organizations, teams, and roles¶
Your company is an organization. Work happens inside teams in that org. Switch org and team in the app header (or call cs.set_org / cs.set_team in the SDK) before you list projects — otherwise you are looking at the wrong lab.
Roles, in plain language¶
Each of organization, team, project, and dataset has a similar ladder:
| Role | Typical use |
|---|---|
| Owner | Create/delete the container, manage members, billing at org level |
| Admin | Settings, invites, day-to-day management |
| Member | Create and edit work (projects, datasets, notebooks) |
| Viewer | Read-only |
A viewer can inspect measurements and notebooks they can reach; they cannot upload, retag, or publish. A member can do lab work but cannot empty the team or change billing.
Access is additive down the tree: you work in a team you belong to; projects and datasets inside that team can narrow who sees them (for example a project limited to named members rather than the whole team).
Invites¶
Owners and admins invite people with a role already chosen. The invitee joins that org/team at the role you picked — they do not inherit a higher role from another team.
Practical rules¶
- Pick the team before creating a project. Datasets cannot float at org level.
- Tags are team-wide. A
needs-reviewtag you create in Lab North is not the same object as one in Lab South. - Instruments belong to a team. Recording
instrument=182as a dataset parameter is how you keep measurement context when the file itself has no serial number — use the same identifier your team puts on the instrument record every time (see Instruments).