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.
Settings is its own place
Everything the workspace holds about people and configuration is managed in Settings, opened from your account menu at the bottom of the sidebar. Settings is a full page with a sidebar of its own: your personal sections — Profile, Notifications, Security — grouped under Account, and the workspace-wide ones — Memory, General, Members, Connections, Workspaces, Billing — under Workspace. Which of the workspace sections you see follows your workspace role: everyone manages their own account; Owners and Admins see the rest.
Every section has its own web address, so a link straight to Settings → Connections in a ticket or a chat message works the way any other link does. Back to app at the top of the settings sidebar returns you to the page you left — the register, document or dashboard you were on when you opened settings.
Teams own the records
Inside a workspace, a team is what actually owns the records it keeps — its documents, its registers and its risks alike; the sidebar hangs a Risk and a Governance section under each of your teams for exactly this reason, and the Governance list is one body of record: documents and registers together. Clicking a team's name opens and closes it, listing what hangs under it; the first entry, Overview, is the team's own page — its name and code, its memory, its activity and its members, all on one page. Each record belongs to exactly one team, and access is decided per team. A few surfaces belong to the workspace rather than to any team and sit above the team sections in the sidebar: the Inbox, the Compliance home, and the Marketplace. Your personal My work lists — My Risks, My Documents, and My Approvals — are also workspace-wide: each gathers your own items from every team you belong to.
That ownership is visible in how they are numbered: everything a team keeps carries the team's code — two or three characters, kept short because every record number the team ever issues has to carry it — so a record's identifier says which team answers for it before you open anything. The kind of record is in there too — PLC- a policy, LIST- a register, EXT- an uploaded file — and no two kinds share a prefix, so a code names exactly one record in the whole workspace. Because documents, registers and connector labels are all numbered under the team code, a team's code is locked as soon as any of the three carries it — the lock asks all three, so nothing can be left holding a code the workspace has moved on from.
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, and it keeps at least one for the same reason — the last team cannot be deleted. Beyond that no team is special: they are listed alphabetically, none of them is marked, and anything created without a team named goes to one of yours.
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 (documents with auditing) and their evidence | team |
| Runs of the documents' processes (the team's Activity) | team |
When you archive a team
Archiving is the non-destructive way to retire a team, and the one to reach for when a team has simply finished. Nothing is deleted — the documents, risks and history stay put. The team just goes out of reach: it disappears from lists and pickers, nothing new can be filed into it, and the actions that work inside a team refuse it. That applies to everyone, the team's own members included, and to workspace owners and admins as well. It also cannot be undone from the app, so move anything you still need into a live team first.
Detail: Teams.
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.