跳到主要内容

组织架构管理

组织架构管理用于维护公司、部门、岗位和员工关系，是审批流、角色权限、消息通知等能力的重要基础数据来源。

配置前先确认以下概念和依赖：

  1. 低代码开发总览
  2. 权限模型
  3. 用户角色权限

组织架构为审批候选人、角色分配、待办通知和部门数据范围提供公司、部门、岗位和员工基础数据。

先理解这页在整个系统里的位置​

组织架构解决的是“有哪些业务身份、这些人处在什么组织关系里”。

它不等于登录账号体系，也不等于权限配置本身。更准确地说：

  • 组织架构：解决员工、部门、岗位、上下级关系
  • 用户角色权限：解决谁能访问什么、谁能操作什么
  • 审批流 / 通知：会把组织架构作为“找人”和“找关系”的基础数据

如果你只是想让一个人能登录系统，通常还需要继续看 用户角色权限；如果你想让审批自动找到部门负责人或某个岗位的人，就要先把组织数据准备完整。

你通常会在这里完成什么​

  • 搭建公司与部门树
  • 为部门补齐岗位
  • 新增员工，并把员工放到合适的部门或岗位里
  • 把员工与系统用户关联起来
  • 为后续审批、通知和权限配置准备可复用的组织基础数据

当前页面大致怎么工作​

当前版本的组织架构页，核心是一个“左侧组织树 + 右侧员工列表”的结构：

  • 左侧组织树：按公司、部门、岗位逐层展开
  • 右侧员工列表：跟随当前选中的节点切换，展示对应范围内的员工
  • 节点操作：新增公司、部门、岗位，编辑节点，查看详情，删除节点
  • 员工操作：新增员工、查看详情、编辑员工、调整岗位、删除员工

如果你的环境启用了不同权限或做过界面定制，按钮位置和可见性可能略有差异；这页以当前默认运行时能力为准。

推荐的整理顺序​

第一次搭组织数据时，建议按下面顺序推进：

  1. 先建公司和部门树
  2. 再补岗位
  3. 然后新增员工
  4. 需要登录系统的员工，再去关联用户
  5. 最后再回到审批、权限、通知模块做联调

这样做的好处是，后面的审批候选人、角色分配、通知接收人都会更稳定，不容易反复返工。

常见任务​

维护公司​

公司节点是组织树的顶层或次顶层节点，通常用来承接集团、多法人主体或多业务单元结构。

新增公司时，当前页面主要会要求你填写以下信息：

属性必填说明
公司名称是组织树中显示的公司名称
描述否对公司的补充说明，适合记录业务边界、主体说明或备注
母公司否指定上级公司，用于形成多层公司结构；不填时通常表示顶层公司

使用建议：

  • 如果当前项目只有一个法人主体，也建议至少建一个根公司节点，后续扩展会更顺
  • “母公司”主要决定树形层级，不直接等同于权限或审批关系

查看或编辑公司时，重点通常是核对名称和层级是否正确；如果发现整棵树挂错层级，优先先修正公司关系，再继续补部门。

维护部门​

部门通常挂在公司下，也可以挂在上级部门下，用来表达事业部、中心、组、科室等层级。

当前新增部门表单通常包含：

属性必填说明
部门名称是部门在组织树中的显示名称
描述否对部门职责、边界或使用场景的补充说明

使用建议：

  • 如果后续审批、权限或报表都要按部门做控制，部门命名要尽量稳定，不要频繁改来改去
  • 一开始不确定是否需要很多层级时，先搭最小可用结构，等业务稳定后再细化

维护岗位​

岗位不是每个项目都必须一开始就配，但当你有“主岗 / 代理岗 / 某岗位审批”这类需求时，岗位会非常有用。

当前页面支持在公司或部门节点下新增岗位，常见字段包括：

属性必填说明
岗位名称是岗位名称，例如“部门经理”“招商主管”“财务专员”
岗位描述否对岗位职责的补充说明
编制人数否用于描述该岗位的计划人数，适合有人岗管理需求时使用

如果你当前只是想先把员工和部门关系跑通，可以暂时不细配岗位；但只要后面会出现岗位审批、岗位筛选或多任职关系，最好尽早把岗位结构补出来。

新增员工​

新增员工适合组织里还没有该员工记录的情况。当前新增员工时，页面通常会先让你把员工挂到当前部门，再选择是否关联用户和是否指定岗位。

常见字段包括：

属性必填说明
姓名是员工姓名
性别是当前默认页面提供基础性别选项
生日否员工生日信息
用户关联是决定是否同时为员工创建用户、关联已有用户，或暂时不关联用户
岗位否把员工放到当前部门下的某个岗位；不选也可以先完成员工创建

关于“用户关联”，通常有三种做法：

  1. 创建新用户：适合这个员工还没有系统账号，希望在新增员工时一并创建
  2. 关联已有用户：适合账号已经存在，只是还没和员工身份绑定
  3. 不关联用户：适合员工暂时只是组织数据，不需要登录系统

编辑员工​

当前默认页面里，编辑员工主要用于维护基础信息，例如姓名、性别、生日。

如果你要处理下面这些内容，通常不在“编辑员工”这个简单表单里完成，而是在员工详情里继续操作：

  • 关联或取消关联用户
  • 查看员工所在组织链
  • 查看任职信息
  • 分配岗位或调整岗位

这点和旧版文档不太一样，实际使用时要注意区分“编辑基础资料”和“管理员工关系”这两类动作。

维护员工与用户的关系​

员工详情页通常会提供“关联用户”或“取消关联”的入口。

这一步很关键，因为它决定了一个业务身份是否真正接入登录与权限体系：

  • 员工已存在但无法登录：通常要检查是否还没关联用户
  • 用户能登录但业务里找不到这个人：通常要检查是否还没绑定员工身份

如果你的下一步是做角色分配或登录后自动识别当前员工，这一步通常不能跳过。

维护任职与岗位分配​

员工详情中通常还能看到任职信息，并支持继续分配岗位。

这适合处理以下场景：

  • 一个人在多个岗位任职
  • 需要区分主岗、副岗、代理岗
  • 审批、筛选或统计要按岗位来做

如果你当前项目还没进入这些复杂场景，可以先只维护“主部门 + 一个主要岗位”的最小结构。

删除公司、部门、岗位或员工​

删除前要格外小心。

当前页面的组织节点删除，通常会连带影响其下级节点；员工删除则会直接影响后续审批候选人、通知接收人和组织统计结果。

删除前建议先确认：

  1. 这个节点下是否还有子节点
  2. 是否已经有员工挂在该部门或岗位下
  3. 是否已经有审批、权限、通知逻辑在使用这些组织数据

如果只是名称不合适，优先考虑编辑，而不是删除后重建。

常见误区​

把组织架构当成权限配置​

组织架构只能说明“这个人在哪个部门、是什么岗位”，不能自动代表“这个人一定能访问哪些页面或数据”。

真正的访问控制仍然要回到 用户角色权限。

先配审批或通知，后补组织数据​

这样最容易在联调阶段反复返工。

审批流里的候选人、通知里的接收人，很多时候都依赖组织关系去解析。组织数据不稳，后面的配置也会跟着不稳。

只建员工，不关联用户​

这样在纯展示场景里没问题，但一旦员工需要登录、被授予角色、接收待办或进入“当前员工”上下文，这一步迟早要补。

使用建议​

  • 把组织树先按“稳定结构”搭出来，再补员工和岗位，维护成本会更低
  • 如果你已经知道后面要做审批，尽量不要省略岗位和负责人关系的梳理
  • 需要把人真正纳入系统访问控制时，及时配合 用户角色权限 一起处理
  • 如果后面要做消息通知，记得同时检查员工资料、联系方式或外部渠道映射是否已经准备好

下一步看哪里​