单位和团队
单位和团队对组织内的嵌套成员资格进行建模：
organization
└── unit
└── team当稳定的部门或工作组需要自己的共享目标或管理范围时，请使用它们。对于临时共享来说，组通常更简单。
存储的角色
| 范围 | 角色 |
|---|---|
| 单位 | unit_admin、base_creator、base_approver、member |
| 团队 | team_lead、variant_creator、variant_deployer、variant_user |
unit_admin 和 team_lead 在组织 API 中定义了成员管理权限。创建者/批准者/部署者标签表达了预期的工作流职责，但它们的存在并不能证明每个构建或部署端点都强制执行。测试具体的工作流程。
会员规则
- 一个单位属于一个组织。
- 一个团队属于一个单位。
- 用户在加入单位或团队之前必须是组织成员。
- 团队成员也应在上级单位；管理路由在添加成员时强制执行层次结构。
- 组织所有者/管理员和范围管理员具有不同的管理权力，如角色和权限范围中所述。
设计指导
仅当单元具有持久边界（例如所有权、审批责任或明确的资源共享范围）时才创建单元。在该边界内为较小的工作组创建一个团队。
示例：
Acme
├── Platform unit
│ ├── Image engineering team
│ └── Security review team
└── Product unit
└── Device application team不要对对授权没有影响的组织结构图进行编码。额外的嵌套会增加陈旧成员身份和意外继承共享的可能性。
安全更改
对于添加、角色更改或删除：
1.记录组织、单位、团队、用户、当前角色； 2. 进行一项更改； 3. 测试允许的操作； 4. 测试被拒绝的操作； 5. 刷新或重新验证以检测过时的会话行为；和 6. 审核目标会员变更的股份。
用户可以属于多个单位和团队。添加新会员资格不会转移或删除旧会员资格。
删除边界
删除一个单位或团队是一项重大操作。不要依赖诸如“资源成为单元级别”或“未分配的资源已归档”之类的通用陈述。删除之前，使用只读清单来识别成员资格、共享、依赖资源、活动工作和外部引用。导出所需的审核记录并确认已部署版本的确切级联行为。
如果影响不明确，请先删除广泛共享和成员，保留对象，并在删除前征求所有者批准。