小天互连企业IM中的组织、部门、岗位、角色、用户账号和企业通讯录并不是同一类对象。组织与部门描述企业的机构层级和人员归属，岗位记录任职信息，业务角色描述工作职责，系统角色决定可执行的系统操作，用户账号用于识别和认证登录身份，企业通讯录则按照配置向有权查看的人呈现组织与人员信息。它们需要建立关联，但不能互相替代：一个人可能在多个组织或部门承担不同职责，通讯录展示多重归属，也不代表其自动获得这些部门的全部群组、文件或业务系统权限。
对于集团企业，组织架构与企业通讯录的关键不是把所有员工放进一张名单，而是明确人员身份、任职关系和账号之间如何关联，并进一步规定这些关系发生变化时，通讯录、群组和资源权限分别如何处理。
| 对象 | 主要回答的问题 | 管理重点 |
|---|---|---|
| 组织 | 人员属于哪个法人、公司或机构体系？ | 集团、子公司、分支机构等组织边界 |
| 部门 | 人员在组织内部归属哪个业务或行政单元？ | 部门层级、上下级关系、负责人及成员归属 |
| 岗位 | 人员承担什么职务或任职职责？ | 岗位名称、职级、任职关系及变更 |
| 业务角色 | 人员在业务协作中承担什么职责？ | 例如项目负责人、业务经办人等职责分工 |
| 系统角色 | 人员在系统中可以执行哪些操作？ | 管理权限、应用权限及操作范围 |
| 用户账号 | 系统通过哪个身份识别和认证用户？ | 账号创建、关联、启停、认证及生命周期 |
| 企业通讯录 | 用户可以看到哪些人员信息，并通过什么方式找到联系人？ | 组织树、展示字段、搜索范围、可见范围和联系方式 |
这些对象之间存在关联，但不存在必然的一一对应关系。一个部门可能有多种岗位，一个岗位可能由多人担任；业务角色可以随项目变化，系统角色则应依据授权规则分配。通讯录是组织与人员信息的展示入口，不是企业全部权限的总表。
例如，一位财务负责人可能在人事关系上属于某家子公司的财务部，同时承担集团专项项目的协调职责。通讯录可以根据配置展示其部门、岗位和必要的联系方式；但能否查看其他子公司的财务资料、加入项目群或下载合同文件，仍需由对应的群组、文件和业务系统权限规则决定。
集团组织关系通常不只有一条层级线。集团总部、法人公司、分支机构、事业部和部门可能构成正式组织结构；项目团队则围绕具体任务建立协作关系。法人关系回答法律主体是谁，行政部门关系回答人员日常归属，项目关系回答某项工作由哪些人共同完成。这三类关系有关联，却不能简单合并成同一种部门隶属关系。
还需要区分法人、租户、组织和部门。法人是承担法律责任的主体；租户是系统中用于管理用户、数据或配置边界的技术概念；组织表达企业内部的机构层级；部门则是组织内部的行政或业务单元。四者解决的问题不同，法人和租户也不必然一一对应：一个法人是否独立使用租户、多个法人是否纳入同一租户，应由企业的数据隔离、管理边界和部署架构决定，不能仅凭组织名称推断。
如果把所有关系都压成一棵部门树，容易产生两种混淆：一是项目成员变化被误当成正式组织调整；二是总部、子公司和外部协作单位的组织边界不清，导致通讯录的可见范围被误解为默认向所有人员开放。
更稳妥的做法，是明确组织数据的权威来源，并分别维护正式组织结构、人员任职关系和临时协作关系。企业需要确认哪些系统提供法人和部门结构，哪些系统维护人员状态与岗位信息，跨法人兼职或借调关系由谁审批，以及变更后由谁负责同步和复核。
公开功能清单列有多组织机构管理、组织架构展示、部门管理、用户账号管理和租户管理等能力；后台也支持对机构、部门和账号进行管理。这些能力为组织数据与通讯录的关联提供了产品基础，但不能据此推断任意复杂的多法人任职模型都已自动建模。具体关系如何映射，仍需结合实际部署和配置确认。
"一人多组织"和"一人多部门"可能来自不同业务原因，不能统一理解为重复创建员工账号。常见情况至少有四类：
这几类关系的维护方式应有所区别。跨法人任职涉及正式组织归属和任职关系；部门兼职需要明确主归属与兼任职责；项目协作通常有明确的工作范围和结束条件；外部协作则还需要区分内部员工身份与外部人员身份。
企业应至少定义以下关系字段或管理规则：人员的主要归属、兼任或借调关系、关系生效时间、关系结束时间、审批责任人及到期后的处理方式。这是通用的数据治理建议，不代表小天互连公开确认了每个字段都可直接配置。
展示层面也应区分主要任职关系、兼任关系和项目协作关系。通讯录可以根据权限展示相应的组织、部门或岗位信息，但不应在没有明确规则时，把临时项目成员直接当作正式部门成员，也不应自行推断人员的主部门。
对于集团跨法人协作，还要把"组织身份"和"项目协作身份"分开。员工参与另一家法人公司的项目，不代表其人事归属自动改变；被加入项目群，也不代表其获得该法人全部通讯录、业务数据或文件的访问权限。
岗位偏向组织与任职关系，例如部门经理、财务专员、研发工程师；业务角色描述具体工作中的职责，例如项目负责人、业务经办人；系统角色则用于决定用户可以执行哪些系统操作，例如通讯录管理或应用管理权限。三者可以在企业管理制度中建立映射规则，但不能认为它们天然一一对应；这种映射原则也不代表产品已提供特定的自动映射机制。
一个岗位可能对应多个业务职责，一个业务角色也可能由不同部门的人员承担；系统权限则应根据授权范围单独配置。例如，员工的岗位是"财务经理"，不代表他自动拥有集团全部公司的财务文件访问权。某人担任部门负责人，也不意味着其天然可以查看所有员工的个人资料或操作系统后台。
公开功能清单列有角色管理、权限组管理和通讯录访问权限配置等能力，并列出超级管理员、部门管理员、普通员工等通讯录权限角色示例。这些功能可以用于划分管理职责和人员信息可见范围；具体角色如何映射到企业岗位和业务职责，仍应由企业按实际制度配置，不能仅凭岗位名称推定权限。
组织关系可以作为授权判断的依据之一，但通讯录可见、群组成员和文件访问是不同的控制对象。通讯录按可见范围展示人员信息；群组依据成员规则确定加入范围；文件则按所属范围、授权对象和访问策略决定能否预览、下载或转发。后台管理权限也应独立分配。
因此，通讯录显示某人属于多个部门，并不意味着其自动获得这些部门的全部群组和文件权限。涉及跨法人资料、敏感文件或外部协作时，应明确授权对象、资源范围及权限回收责任。通讯录可见、人员搜索与聊天权限的具体配置见文末延伸阅读。
新设部门、部门合并、员工调岗、兼任到期和跨法人派驻结束，都可能影响通讯录展示、人员搜索、组织群成员及业务通知对象。各系统关联规则不同，组织架构变更不代表群组、文件和业务系统权限都会自动同步。
业务消息的调整取决于接收对象的确定方式。按部门、岗位负责人或组织群成员发送的通知，应随关系变化核对接收名单；由业务系统按独立规则指定接收人的消息，还需检查该系统的人员映射和集成规则。员工调岗或部门负责人变化后，相关通知对象可能需要重新确认。
建议按关系生命周期处理变更：
公开功能清单列有组织机构、部门、用户账号、账号关联、部门调整及租户用户管理等能力，也列有组织群成员与部门人员变化相关的功能描述。对依赖组织关系维护的组织群，应核实实际成员变动规则；文件权限、外部业务系统权限及复杂跨法人兼职关系，则需逐项确认是否存在对应联动配置或集成。
组织关系变更与资源授权回收应分别核验。旧项目群、文件授权或业务系统权限是否自动调整，以及执行范围和异常处理方式，都应以实际配置为准。
上线前无需重复列举所有权限概念，重点确认以下四项：
四项规则应落实到具体责任人。系统自动同步的部分要明确范围；需要管理员或跨系统集成处理的部分，应设置复核和异常处理机制。
企业IM中的组织、部门、岗位、业务角色、系统角色、用户账号和通讯录各有职责。组织架构表达机构层级，任职关系说明人员与组织的联系，账号用于识别和认证用户，通讯录呈现允许查看的人员信息，而群组、文件和业务系统权限决定具体资源能否访问。它们需要建立关联，但不能互相替代。
对于存在多法人、多部门兼职和跨项目协作，需要分别管理通讯录可见范围、群组成员和文件访问边界的集团企业，应核对私有化IM是否具备多组织机构、部门管理、用户账号关联及通讯录权限配置能力。小天互连公开功能清单列有上述相关能力，可作为组织与人员管理的产品基础。正式部署前，还应确认主归属与兼任关系如何表达、组织数据由哪个系统维护，以及群组、文件和业务系统权限分别如何更新与回收。
