Teams

<!-- Reviewed 2026-09-08 (the sidebar gained a Chat entry): the covered AppSidebar.tsx now carries a Chat link between Inbox and Compliance, so the nav this page describes has one more workspace-level entry. NOTHING HERE MOVES, and that is a finding rather than an omission: this page is about creating a team, its roster, and what deleting one destroys, and the new entry is neither — it opens the assistant, which is documented where the assistant is (intelligence/ai-review.md → "Chat as a screen"). The team rows, how they expand and what they contain are untouched. --> <!-- Rewritten 2026-09-07 (the team page is ONE page): the four tabs are gone. Memory and Activity are sections of one column, the roster is the panel beside them, the name is renamed in the title and the code sits next to it. In the sidebar the team row now expands rather than navigates, and Overview is an entry beside Risk and Governance — so "clicking a team's name opens its home page" was no longer true of either half of this page's covered code. Deleting a team is unchanged; it just lives at the foot of the members panel. --> <!-- Amended 2026-09-08 (no team is special — owner: "Can you remove the default team feature from completely"): a workspace no longer has a DEFAULT team. It had one flagged team that sorted first, wore a badge, could not be deleted and silently received anything created without a team. The badge and the sort are gone, deletion now refuses only the workspace's LAST team, and the fallback destination is the workspace's oldest team — the same row the flag used to mark, since it was created at workspace birth. Same diff: new team codes are capped at three characters ("The doc code size must have limit 3 letters"); existing longer codes are untouched and keep numbering, because the numbers already issued cite them. --> <!-- Amended 2026-09-08 (the header is the name — owner: "edit name like the document name editing in document", "a real minimalist design"): the pencil, the Save and Cancel buttons and the two-sentence paragraph about document numbering are gone. The title IS the field, autosaved on a pause exactly as a document's name is, the code is quiet text beside it, and the numbering sentence is that code's tooltip. --> <!-- Rewritten 2026-09-08 (the members panel, pared back): the panel's two explanatory paragraphs are gone — the count now sits in its heading, the role names live in the role menu, and "you cannot remove your own access" is simply the disabled remove control on your own row. Its real defect was worse than its wordiness: the panel listed NOBODY, on every team, because the page re-read the roster in a loop and discarded each answer. It now says "loading" while it reads and says so when the read fails, so an empty list is never shown in place of an unknown one. This page describes the panel by what it shows, so both halves changed here. --> <!-- Reviewed 2026-09-07 (the mode left team settings): the covered TeamDialog, the team overview page and teams.ts lost the permission-mode field entirely — it is per CONVERSATION now, chosen in the chat (owner: "It's supposed to be inside the user chat part like claude. Not in settings."). The section above says so and points at the chat rather than describing a control this page's Settings tab no longer has. Nothing else about a team changed. --> <!-- Reviewed 2026-08-27 (document clause audit retired): this page's covered code changed only where the audit touched it — `teams.ts` no longer lists `audit_reports` among a team's owned tables, and `withApi.ts` lost the `auditReports` resource gate. Nothing this page describes to a reader moved: a team still owns its documents and risks, and the permission rungs are unchanged. Confirmed rather than rewritten. --> <!-- Sidebar reviewed 2026-08-13: the short-lived workspace-level Partners entry was REMOVED again — partner management is Alchex's own back office (its own console outside the app), never a customer-facing section. The team sections this page documents are unchanged. --> <!-- Sidebar reviewed 2026-08-14: "My Approvals" joined the personal My work group (documented under Review → Submit and approve). The team sections this page documents are unchanged. --> <!-- Sidebar reviewed 2026-08-17: the account menu's Settings entry now navigates to the full-page settings surface (its own left rail) instead of raising a modal overlay — documented under Getting started → Workspaces and teams. The team sections this page documents are unchanged. -->

A team is what owns controlled documents, and team membership is what gives people access to them. This page covers running them.

Creating a team

Only a workspace Owner or Admin can create a team. Every workspace starts with one, so you are adding to that rather than starting from nothing.

A team needs a name, and can have a short code — two or three letters or digits — used to label everything the team keeps — its documents, its registers and its connector labels, which share one numbering scheme: a prefix for the kind of thing, the team code, then a number. Codes have to be unique within the workspace — a clash is refused rather than silently accepted, so two teams can never share a label.

Codes are short on purpose. Every record number the team issues carries it (PLC-HR-001), and a long code makes every one of those numbers long — the thing people read, quote and type. Three characters is the ceiling for a new code. Teams coded before that limit keep the code they have and keep numbering with it: the code is immutable precisely because the numbers already issued cite it, and shortening one now would leave those citations pointing at a label that no longer exists.

Once a team's code is in use, it can no longer be changed. That is deliberate: the code is baked into every record already numbered under it, and those numbers are what someone cites when they point at a specific record. Changing the code would leave those citations pointing at a label that no longer exists. Pick the code when the team is quiet, not after a year of records.

All three kinds of coded thing hold the code down. The lock used to check the team's documents and registers only, so a team whose sole numbered rows were connector labels (CON-…) could still rename its code and orphan every one of them. It now checks the labels too, so the rename is refused while anything at all carries the old code.

When you create a team you can add its members in the same step, each with their role. Doing it there rather than afterwards means the team is never briefly a team with no Writers.

If your workspace has a control catalog available, creating a team can also set up that team's own copy of the controls. Each team's controls are its own: assessing a control on one team does not assess it on another.

Managing membership

Team membership is managed on the team, not on the workspace member roster — one person can be on several teams with a different role on each, so there is no single value to edit centrally.

Who can change it: a team Owner, or any workspace Admin or Owner.

Two things to know:

• You cannot remove your own Owner access from the team screen. It would leave you unable to undo the change you just made.
• Workspace Admins and Owners do not need to be members. They already count as team Owner on every team. Adding them explicitly is harmless but changes nothing.

Removing someone from a team removes their access to that team's documents and nothing else. Their contributions stay attributed to them.

The team's home page

Clicking a team's name in the sidebar opens and closes it, listing what hangs under it. Overview is the first of those entries, beside Risk and Governance — that is the team's own page, and like the two lists it is an ordinary link you can bookmark or open in a new tab. Clicking the team no longer navigates anywhere, so reaching for one of its lists cannot land you on the page by accident.

The page is one page. Nothing on it is behind a tab or a menu:

• The name and the code, at the top, on one line. The name is a field: click it and type. There is no pencil, no Save and no Cancel — it saves itself a moment after you stop typing, the same way a document's name does, and pressing Escape puts the old name back. The code sits beside it in small type and is never editable — it numbers the team's records — and hovering it tells you what a document made here is numbered.
• Memory — the team's memory page: what the team owns, how it works and what it has decided, written by the assistant and edited by the team. Only the team's members and workspace admins can open it; nobody on another team can read it.
• Activity — what the team's procedures are doing: every workflow run, with runs waiting on a person and runs that did not finish pinned at the top, exactly as the compliance record's own Activity tab shows them workspace-wide. A run opens into its receipts.
• Members, in the panel beside them — who is on the team and with what role, managed in place. It is a list and nothing else: the number of members is in its heading, a role is changed by clicking it, and Add a member is the last row of the list. Someone you may not remove — yourself, or a workspace owner who is on every team by right — simply has no working remove control on their row. While the list is still being read it says so, and if it cannot be read it says that too: an empty panel always means an empty team, never a failed read. For workspace owners and admins the Delete team door is the last thing in that panel.

If you do not have rights to manage the team, the page still opens — read-only, with the controls disabled and the name shown but not typeable — so you can see how it is configured without being told off for looking. Creating a team is unchanged: the + beside Your teams opens the create window. There is no ⋯ menu anywhere on a team — not in the sidebar, not on the page — because everything a team offers, deleting it included, is on the page in the open.

The team's Activity is its run history. Every run of every process from the documents the team governs is a line of that feed — the process on the document, what it did (ran, is waiting on a decision, did not finish), when — newest first, with the document's name linking to the document, where the Workflow panel keeps the run's receipts. Runs waiting on a person and runs that did not finish are pinned above the stream. A run keeps its line even after its document is permanently deleted; it just stops linking anywhere. There is no separate run-history page and no side panel: the feed you already read is the log.

What the assistant may do without asking

This is no longer a team setting. It moved into the chat itself, where you can see it while you work: the control sits beside the message box and applies to the conversation you are in. A team's page does not carry it.

It moved because a conversation was never part of a team. There was no way to read "this chat's setting", so the app took the most cautious setting across every team you belonged to — which meant one team left on Ask governed your chats everywhere, and nothing could tell you which team was deciding. See AI review and assistance.

Deleting a team

This is the part to read before you do it, because deletion is destructive and asymmetric:

The asymmetry is deliberate. Documents, risks and registers are working material owned by the team. Control assessments are a record of what you evaluated and when, and that record has to outlive a reorganisation — so it survives the team that produced it. A control sits in the team's Governance list like any document, but its assessment record is stored with the control itself, which is what lets it survive.

Two consequences worth spelling out:

• Deleting a team is not a way to clean up controls. They persist, hidden.
• Deleting a team is a way to permanently lose documents. If any of them matter, move them to another team first.

The door is on the team's home page, shown only to workspace owners and admins. A workspace keeps at least one team, so the last one cannot be deleted — that is the only team that is ever refused, and no team is otherwise special. Deletion asks you to confirm, and cannot be undone.

Archiving a team

Archiving is the non-destructive alternative to deleting, and it is what you usually want for a team that has finished its work. Nothing is destroyed: the team's documents, risks, controls and history all stay exactly where they are, still owned by that team.

What changes is reach. An archived team is out of bounds for everyone — including the people still on it. It stops appearing in team lists and pickers, it can no longer be chosen as the home for a new record, and the actions that operate inside a team (inviting someone, setting clause scope, provisioning controls) refuse it. Workspace owners and admins are refused too; being an admin does not reopen a team the workspace has closed.

That "including its own members" used to be untrue, and quietly so: a member of an archived team could still act inside it through a few of those doors, even though the team had vanished from every list they could see — while an admin was correctly refused at the same door. Archiving now means the same thing to everyone who meets it.

⚠️ Archiving cannot currently be undone from the app. Nothing is lost, but there is no un-archive button — the team and everything filed under it stay out of reach. So move anything you still need into a live team before archiving, exactly as you would before deleting.

Move documents instead

Most of the time the thing you actually want is to move the documents somewhere else and leave the empty team alone, or move them and then delete. Documents can be reassigned to another team, which keeps their history intact — a much better outcome than deleting and recreating.

How many teams

Teams are an access boundary, not filing. Create one when a distinct group of people is accountable for a distinct body of documents; use the document library's filters when you just want to organise by topic.

The trade-off is real in both directions: too few teams and you cannot give someone narrow access; too many and every team is another membership list to keep correct, with documents stranded where the people who need them cannot see them.

More on the model: Workspaces and teams.

Next

• Roles and permissions — what each team role can do.
• Members and invitations — getting people into the workspace first.