Workspaces and teams
The two containers everything else sits inside — what belongs to a workspace, what belongs to a team, and how that decides who sees what.
Alchex has exactly two containers, and knowing which one a thing lives in answers most "why can't I see this?" questions. This page is that model.
The workspace is your organization
A workspace is the outer boundary. It holds your members, your teams, your settings and your billing, and it is the edge that data never crosses: nothing in one workspace is visible from another, ever.
You will normally have one. People end up with more than one when they genuinely operate separate organizations — a consultancy running its own management system alongside a client's, for example.
The workspace also has an address derived from its name, which is why workspace names are claimed globally rather than being free text.
Teams own the documents
Inside a workspace, a team is what actually owns controlled documents. A document belongs to exactly one team, and access is decided per team.
This is the part worth internalising: being a member of the workspace does not let you see documents. Someone who is in the workspace but on no team cannot read that team's documents — not even to look. Access comes from team membership, and only from there.
Every workspace starts with one team so there is always somewhere for a document to live.
Who can see what
Two independent sets of roles decide this, and they answer different questions.
| Workspace role | Team role | |
|---|---|---|
| Answers | who runs the organization | what you can do to documents |
| Values | Owner, Admin, Member | Reader, Writer, Owner |
| Chosen when | you invite someone | you add them to a team |
| Governs | invitations, settings, billing, creating and deleting teams | reading, writing, submitting, approving, publishing |
The same person can hold different team roles on different teams — Writer on one, Reader on another — which is the normal way to give someone broad visibility and narrow authorship.
One shortcut connects the two axes: a workspace Admin or Owner is treated as team Owner everywhere, without being added to any team. It is a real grant of authority over every document in the workspace, so give those roles to people who genuinely administer it. Everybody else has exactly the team roles you gave them.
The full table of what each team role can do is on Roles and permissions.
How many teams should you have?
Fewer than you think. A team is worth creating when a distinct group of people is accountable for a distinct body of documents. It is not worth creating to mirror your org chart.
Signs you actually need another team:
- A set of documents that a different person approves.
- Documents some workspace members genuinely should not read.
- A separate site, entity or client with its own management system.
Signs you do not:
- You want folders. Teams are an access boundary, not filing.
- You want to label documents by topic. That is what the document library's filters are for.
Splitting later is more work than starting simple, but over-splitting early is worse: every extra team is another membership list to keep correct, and a document in the wrong team is invisible to the people who need it.
What lives where
| Thing | Lives in |
|---|---|
| Members and invitations | workspace |
| Billing, licences, plan | workspace |
| Workspace name and address | workspace |
| Teams | workspace |
| Controlled documents and their drafts | team |
| Approvals, comments, version history | with the document, so the team |
| Risks | team |
| Controls and evidence | team |
When you delete a team
Deleting a team is not a tidy-up — it is destructive, and asymmetrically so. Its documents and risks are permanently deleted. Its controls are hidden rather than deleted, so their evidence and audit history survive.
That asymmetry is deliberate: the record of what you assessed and when has to outlive a reorganisation. It also means deleting a team is not a way to clean up controls.
Detail: Teams.
Next
- Start here — the shortest path to a published document.
- Workspaces — creating, renaming, switching, closing.
- Roles and permissions — the full rule.