Units і teams

Units і teams моделюють nested membership всередині organization:


organization
└── unit
    └── team

Використовуйте їх, коли stable department або working group потребує власного share target або administrative scope. Groups часто простіші для ad hoc sharing.

Stored roles

Scope	Roles
Unit	`unit_admin`, `base_creator`, `base_approver`, `member`
Team	`team_lead`, `variant_creator`, `variant_deployer`, `variant_user`

unit_admin і team_lead мають defined membership-management authority в organization API. Creator/approver/deployer labels виражають intended workflow responsibilities, але їхня presence не доводить enforcement кожним build або deployment endpoint. Test specific workflow.

Membership rules

Unit belongs to one organization.
Team belongs to one unit.
User must be organization member перед join unit або team.
Team member should also be in parent unit; administrative routes enforce hierarchy when adding members.
Organization owners/admins і scoped administrators мають різні management powers, описані в Roles and Permission Scope.

Design guidance

Create unit only if має durable boundary: ownership, approval responsibility або distinct resource-sharing scope. Create team для smaller working group inside that boundary.

Example:


Acme
├── Platform unit
│   ├── Image engineering team
│   └── Security review team
└── Product unit
    └── Device application team

Do not encode org chart без effect on authorization. Extra nesting збільшує chance stale memberships і unexpected inherited shares.

Safe changes

For add, role change або removal:

record organization, unit, team, user і current roles;
make one change;
test permitted operation;
test denied operation;
refresh або reauthenticate для stale session behavior; and
review shares, whose target membership changed.

Users can belong to multiple units і teams. Adding new membership не transfer або remove old one.

Deletion boundary

Deleting unit або team , material operation. Do not rely on generic statements на кшталт «resources become unit-level» або «unassigned resources are archived». Before deletion use read-only inventory: memberships, shares, dependent resources, active work, external references. Export required audit record і confirm exact cascade behavior deployed release.

If impact not clear, remove broad sharing і members first, preserve object, seek owner approval before deletion.