Skip to main content

Put a User in a Team

Goal​

Put a person in a team, so the team's records reach them under the My teams' and Mine and my teams' policies.

Prerequisites​

  • You are signed in to the Admin Control Center as a platform administrator.
  • The person already exists as a user.

Steps​

  1. Open the Teams page from the left navigation, under Users.
  2. Tick the team's row and select Manage members. A panel opens listing your tenant's users, with a search box that narrows on name or email.
  3. Tick the people who should be in the team; untick anybody who should not. The count beside the search box is the whole membership, so it does not drop while you are filtering.
  4. Select Save.

Membership takes effect immediately, in every environment. There is no delay to wait out: saving copies the change into each environment and bumps its security counter, which is what every cached decision is keyed on.

Teams are edited here, not in an app​

Teams, users and roles belong to your tenant, not to any one environment. Each environment holds a copy of them so that records there can be owned by a team and the policies have members to read — and those copies are read-only in an app. If you open the Teams or Team Memberships table in a model-driven app you can look, but not change: creating a team there would make one that exists in a single environment, belongs to nobody's account, and never appears on this page.

That is why the platform refuses the write and names this screen instead. Organisational Units are the exception and stay editable in an app — a unit really is one environment's own org chart, not a copy of anything.

Who heads a unit​

An Organisational Unit carries a Manager — a lookup to a user, on the unit's own form. It is the head of that unit, and it is on the unit rather than on each person on purpose: a unit having a head is an organisational fact, where who reports to whom individually is personnel data the platform deliberately does not hold. One row to keep current instead of one per employee, and it cannot go stale for somebody the day they change jobs.

Set it in an app, on the Organisational Units table, the same way you set the unit's parent.

Nothing reads it yet. It is there for process routing: "send it to my manager" is the commonest approval rule there is, and because units already form a tree through Parent Unit, walking that tree upward from a unit's manager is also the whole escalation ladder — the approver's approver, and theirs. A business process will be able to say that without anybody writing code.

Assign is not this​

Assign hands one record to a person or a team — it changes who owns that record. It says nothing about who is in a team.

You will not find Assign on a Team, a User or an Organisational Unit at all, and that is deliberate: those are the tables ownership is expressed in terms of. A row in one of them is a principal, not something a principal owns, so "who owns this user" is a question the platform has no answer to — nothing ever reads it.

Why membership matters​

Three of the built-in policies read it (see Grant a Role Access to Records):

  • My teams' records — records owned by a team the person belongs to.
  • Mine and my teams' — those, plus the ones they own personally.
  • Records I own — deliberately not team records, which is the single most common surprise in any system like this. Somebody who says "I can't see my own record" is usually holding this one, looking at a record their team owns.

Membership never grants a permission. It decides which records the permissions somebody already holds can reach. If they cannot do something at all, they need a role, not a team.

Troubleshooting​

  • The Members list is empty. — the tenant has no users yet, or they could not be loaded. Create the people on the Users page first.
  • "The team was saved, but the environments could not be updated: …" — the membership is stored; only the copies in your environments are behind, and the message says what stopped it. Fix that and save the membership again; it is repeatable and brings them into step.
  • The person still cannot see the team's records. — check three things in order: that their role grants the permission at all, that it is granted under a policy that reads teams (not Records I own), and that the record is actually owned by the team rather than by a person.
  • I added a membership and nothing changed. — it is the record's owner that has to be the team. Set the record's Owner field to the team; membership decides who that then reaches.
  • I cannot edit the Teams table in my app. — correct, and see above: the real team is on the Admin Control Center's Teams page. The table in the app is a copy, so that records there can be owned by a team.