Create a Team
Goal
Create a team so that records can belong to a group of people rather than to one person — and so that policies like "my team's records" have somebody to match.
Prerequisites
- You are signed in to the Admin Control Center as a platform administrator.
- The people you want in the team already exist as users.
Steps
- Open the Teams page from the left navigation, under Users.
- Select New. A drawer opens.
- Enter a name — this is what people see wherever a record's owner is shown — and, optionally, a description of what the team is for.
- Select Save.
- Staff the team: with its row selected, choose Manage members (the same command is on the team's own drawer). Tick everybody who belongs to the team, then select Save. The list is your tenant's users, with each person's email under their name so two people of the same name are told apart, and a search box above it that narrows on either.
Members are added after the team is saved, not while creating it — there is nobody to add to a team that does not exist yet, so the create form points you at the panel instead.
The team is now available in every environment: a record can be owned by it, and it can be picked wherever an owner is chosen.
A team is not a role, and the difference matters
This is the one thing worth being clear about, because both are lists of people:
| A team | A role | |
|---|---|---|
| Answers | Which records somebody reaches | What somebody may do |
| Given to | People, by putting them in it | People, on the Users page |
| Can own records | Yes — a record can belong to a team | No |
| Comes from | This page | The Roles page; its permissions from a solution |
Putting somebody in a team never gives them a permission. If a person cannot create an account, adding them to a team will not help — they need a role. What a team changes is the reach of the permissions they already have: a policy of "my team's records" finds more once they are in the team.
Why teams live here and not inside an app
A team is like a user: it belongs to your tenant, not to one environment. Create it once and it appears in Dev, Test and Prod alike, as the same team — so a record owned by "Support" in one environment and one owned by "Support" in another are owned by the same group.
That is also why the team's name can be changed freely, unlike a role's logical name. Nothing refers to a team by name; renaming one changes only what people read, everywhere.
Editing and deleting
Click a team's row (or tick it and select Edit) to rename it, change its description, or change who is in it. Removing somebody takes effect in every environment: they stop reaching the team's records.
Delete asks each environment whether the team still owns any records before it will go through. If it does, you are told where — the environment, and which tables — and the delete is refused until those records are given another owner. Deleting a team does not delete anybody's account; the people simply stop being in it.
What happens behind the scenes
The team is stored once, alongside your users. After every save, the platform copies it — and its membership — into each of your environments, which is what lets a record there be owned by it. Deleting a team removes those copies too, so it stops being offered as an owner.
Troubleshooting
- "A team named … already exists." — the name is what every owner field shows, so two teams cannot share one. Pick a different name.
- Delete is greyed out in the confirmation. — the team still owns records, or one of your environments could not be reached to ask. The message names which. Reassign the records, or try again once the environment is back.
- "The team was saved, but the environments could not be updated: …" — the team itself is safe; only the copies in your environments are behind, and the message says what stopped it (most often the Application Layer being unreachable). Fix that, then save the team again — the update is repeatable and brings every environment into step.
- Somebody is in the team but still cannot see the team's records. — check they have a role granting them access, with a policy that includes team records. Membership decides which records a permission reaches; it does not grant the permission.
- Delete acts on one team at a time. — each delete asks your environments a question of its own, and a batch would turn one refusal into an all-or-nothing decision.