Teams
Creating teams, managing who is on them, and the asymmetry in what deleting a team destroys and what it keeps.
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 used to label its documents. Codes have to be unique within the workspace — a clash is refused rather than silently accepted, so two teams can never share a label.
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.
Team settings
A team's settings are reachable from the team itself. If you do not have rights to manage that team, the screen still opens — read-only, with the controls disabled — so you can see how it is configured without being told off for looking.
Deleting a team
This is the part to read before you do it, because deletion is destructive and asymmetric:
| What happens | |
|---|---|
| Documents | Permanently deleted, including drafts and version history |
| Risks | Permanently deleted |
| Controls | Hidden, not deleted — evidence and assessment history are kept |
The asymmetry is deliberate. Documents and risks 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.
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.
Deletion asks you to confirm, and cannot be undone.
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.