ObjectOS用户与组织
搭建业务单元树、添加和邀请用户、管理成员资格与团队，以及开通服务账号。
关于你的部署中都有谁的一切——人员、他们所在的组织树、他们协作的团队，以及代表他们行事的服务账号——都在 Setup → People & Organization（人员与组织，/apps/setup）中管理。
底层的身份对象（sys_user、sys_organization、sys_member、sys_business_unit、sys_team、sys_invitation、sys_api_key ……）存在你的项目数据库中；每个对象表示什么，参见身份层表格。
**90% 的日常管理就是把人分配到岗位。**岗位、其背后的权限集以及安全基线都随平台和你安装的应用一起交付。你的工作是人这一侧——本页所讲的内容——以及分配这一侧，后者在权限分配中讲解。
搭建组织（业务单元）
Setup → People & Organization → Business Units（业务单元）。
业务单元树是访问模型中唯一的层级结构：它决定可见性深度（unit、unit_and_below）和委派管理边界。在初始上线时搭好它，之后仅在组织架构调整时再修改。
- 默认的 Org Chart（组织架构图）标签页把树渲染为可展开/收起的缩进树形表格。
- 先创建根节点（kind 为
company），再用 New（新建）添加子节点，并在表单中选择 Parent Business Unit（上级业务单元）。division/department/office/cost_center这些 kind 只是显示提示——无论选哪种，树的工作方式都一样。 - 调整架构时，Edit（编辑）某个单元并修改其上级即可。树视图是只读展示——变更上级要通过记录表单完成，而不是拖拽。
三个名字相近的东西，三种不同的职责——别混淆：
| 对象 | 职责 |
|---|---|
业务单元（sys_business_unit） | 层级结构。驱动可见性深度和委派管理边界 |
团队（sys_team） | 扁平的协作组。团队只接收共享；从不承载能力 |
组织（sys_organization） | 租户本身——你公司的账户，而不是其中的一个节点 |
让树保持浅层、如实反映你的真实结构。如果某个东西应该按组织结构影响人们能看到哪些记录，它是业务单元；如果只是一个供人共享记录的群组，它是团队。
添加人员
Setup → People & Organization → Users（用户）。三条入口，都是一等公民：
| 路径 | 何时使用 | 会发生什么 |
|---|---|---|
| Invite User（邀请用户，工具栏） | 此人有可达的邮箱 | 发送邀请；对方接受时自行设置密码 |
| Create User（创建用户，工具栏） | 不想走邮件流程——或只有手机号的员工 | 创建可直接登录的账户（邮箱和/或手机号）；生成的临时密码只显示一次，并强制首次登录时修改密码 |
| Import（导入，工具栏） | 从 CSV/Excel 批量入职 | 带列映射和 dry-run 预览的向导；每批最多 500 行。可选择登录策略：无密码（首次通过 OTP/魔法链接/重置链接登录）、发送邀请，或一次性临时密码 |
待接受的邀请列在 Setup → People & Organization → Invitations（邀请）下。
同样的流程也可通过 REST 完成（ObjectStack 14.3+），用于脚本化入职：
# 创建可直接登录的账户，可选生成一次性密码
curl -X POST https://crm.example.com/api/v1/auth/admin/create-user
# 批量导入行 / CSV / XLSX（最多 500 行），支持 dry-run 和 upsert 模式
curl -X POST https://crm.example.com/api/v1/auth/admin/import-users请求体、密码策略和仅手机号账户的细节，参见认证 → 管理员用户管理。
把人放进组织树（成员资格）
把一个人放进组织树是一条独立的记录：Business Unit Member（业务单元成员）行（sys_business_unit_member——用户 + 业务单元，其中一条标记为 primary）。基于深度的可见性和 unit_and_subordinates 共享都通过这条成员资格解析，所以不要跳过它——没有成员资格行的用户对基于深度的规则来说是不可见的。
当某人调换部门时，更新其业务单元成员行，并重新锚定其岗位分配——参见权限分配。
团队
Setup → People & Organization → Teams（团队）。团队是扁平的协作组：共享规则和记录共享可以指向它们，但它们从不承载权限集。当一个跨部门的群组需要看到某批记录，而又不想改变任何人的职能或组织树时，就用团队。
用户生命周期
日常生命周期操作位于每个用户的行菜单和记录头部：
| 操作 | 效果 |
|---|---|
| Ban / Unban（封禁 / 解封） | 立即阻止（或恢复）登录 |
| Unlock Account（解锁账户） | 提前清除暴力破解锁定 |
| Set Password（设置密码） | 直接设置密码；也能生成强制轮换的一次性临时密码 |
| Impersonate User（模拟用户） | 以该用户身份打开会话，用于支持和验证（会话会被记录） |
要停用某人，先 Ban（封禁）——登录立即被阻止——之后再从容移除其岗位分配和成员资格。完整的离职流程见权限分配。
用户的自助密码找回依赖已配置的邮件或短信发送服务。在接通之前，管理员的 Set Password（临时密码、强制修改）是可靠的兜底手段。
服务账号与 API Key
集成和无头 Agent 使用 API Key（sys_api_key）认证——一种绑定到用户的长期编程凭据。用该 Key 发起的每次调用都以那个用户的身份、按那个用户的权限运行。
凡是超出个人脚本用途的场景，都请创建专用的服务用户：
- 为该集成 Create User（创建用户，无需邀请）。
- 为它分配能覆盖该集成所涉对象的最小权限集——绝不要用管理员权限集。
- 为它签发 API Key，可在 Setup → Connect an Agent（接入 Agent）中操作，或通过 REST：
curl -b cookies.txt -X POST https://crm.example.com/api/v1/keys
# → { "key": "osk_..." } —— 只显示一次；存入你的 secret managerKey 的用法、请求头和轮换见 API 访问；用 Key 接入 AI Agent 见接入 AI 工具（MCP）。
FAQ
**新用户几乎什么都看不到——是坏了吗？**不是：这正是基线在正常工作。每个已认证用户都获得叠加式的 member_default 基线；真正的访问权限在你分配岗位时到来。
**部门还是团队？**部门 = 业务单元（层级、可见性）。团队 = 扁平的共享群组。
**能删除内置权限集吗？**不能——member_default、organization_admin 这类权限集是平台基线。随应用交付的权限集可以被覆盖（overlay），或干脆不分配。