研发平台对接钉钉时，任务通知和组织同步经常被混在一起讨论，结果要么把人员变动做成任务提醒，要么把工作项进展写进组织架构。边界问题的实质是两类数据分开定义：组织同步负责“谁在哪个部门、账号是否有效”，任务通知负责“哪条工作项变化通知谁、通知到什么程度”。本文按这一口径给出字段清单、触发规则、角色分工和转岗示例，帮助对接团队产出一份可评审、可维护的边界规则。
要点总览（TL;DR）
- 边界划分的口径：组织同步只处理身份与归属（部门、人员、账号状态、角色标识），任务通知只处理事件与接收人（工作项状态变化通知谁、通知到什么程度）。
- 组织同步要逐字段写明主数据来源、同步方向和生效时点，主数据只保留一侧可改，入职、转岗、离职分别对应新增、变更、停用，并写明延迟容忍度。
- 任务通知按角色而非按人配置接收对象，触发条件按工作项类型和状态流转定义，通知粒度区分即时提醒与汇总摘要，并设置免打扰和超时升级规则。
- 边界规则由接口或集成负责人、研发流程负责人、钉钉管理员共同评审，交付字段清单、通知触发清单、变更记录和异常处理台账。
- 上线前用完成检查清单核对，主数据双向可改、接收人按人硬编码、无异常台账属于阻断项，需先修正再上线。
先划清两类边界：组织同步管身份，任务通知管事件
边界划分的判断标准可以归结为一句话：这条数据描述的是“人属于哪里”，还是“发生了什么”。前者归组织同步，后者归任务通知。两类数据在系统里可能都表现为一条记录或一条消息，但它们的来源、维护责任和变更频率完全不同，混在一起会让规则无法评审，也无法排查问题。
组织同步的对象是部门层级、人员基本信息、账号状态和归属关系，解决“人是谁、在哪个组织、账号能不能用”。任务通知的对象是工作项的状态流转、字段变化和接收人，解决“什么变化通知谁、通过什么渠道、通知到什么程度”。
| 数据类别 | 归属模块 | 判断依据 |
|---|---|---|
| 部门层级、人员姓名与工号、账号启用停用、岗位或角色标识 | 组织同步 | 描述身份与归属，变更由人事或组织管理动作驱动 |
| 工作项状态流转、负责人变更、截止日期调整、评论与提及 | 任务通知 | 描述事件，变更由研发协作动作驱动 |
| 目录认证、单点登录、密码策略 | 企业身份与账号集成 | 属于账号认证范畴，本文不展开 |
| 群管理、沟通话术、消息回复时效 | 团队沟通与信息同步 | 属于日常沟通规范，本文不展开 |
边界不清通常有两种典型表现。一种是把人员变动做成任务通知：新员工入职后，系统给项目负责人推送一条“请处理新成员”的任务，而组织归属本身没有更新，导致权限和可见范围仍然错误。另一种是把任务进展写进组织同步：把“某项目当前阶段”当作人员属性同步到通讯录，组织数据被业务状态污染，后续人事变更时无法判断哪些字段该由谁维护。出现这两类现象，说明边界定义需要重做，而不是调整通知频率。
组织同步边界：字段清单、同步方向与生效时点
组织同步的规则要落到字段级别，每个字段写清来源系统、是否必填、以哪一侧为准。只写“同步组织架构”无法评审，也无法在出问题时定位责任。
| 字段 | 必填 | 主数据来源 | 同步方向 | 生效时点 |
|---|---|---|---|---|
| 部门层级与部门编码 | 是 | 人事系统 | 单向写入钉钉通讯录 | 组织调整审批通过后同步 |
| 人员姓名、工号、手机号或邮箱 | 是 | 人事系统 | 单向 | 入职建档后同步 |
| 账号状态（启用、停用） | 是 | 人事系统 | 单向 | 离职流程办结后停用 |
| 岗位或角色标识 | 按需 | 人事系统或研发平台 | 单向，需明确唯一来源 | 转岗或角色调整生效日 |
| 兼职与多部门归属 | 按需 | 人事系统 | 单向 | 兼职审批通过后同步 |
主数据归属是这张表里最需要先定的一项。常见做法是以人事系统为准，钉钉通讯录作为接收侧，研发平台从同步结果中读取人员与部门关系。这样做的原因是人事动作有审批记录和生效日期，便于追溯。如果两侧都允许修改，同名人员、部门调整和离职停用就会出现互相覆盖，排查成本很高。同步方向确定后，接收侧应关闭对应字段的手工编辑入口，或者至少建立变更审批，避免绕过规则。
生效时点要按人员生命周期分别定义。入职对应新增，转岗对应部门与角色变更，离职对应停用。每个动作都要写明延迟容忍度，例如“离职办结后当日停用，最长不超过一个工作日”，并说明延迟期间的处理方式，比如是否保留只读权限。延迟容忍度是运维和审计的共同依据，缺少这一项，同步是否正常就无法判断。
例外场景需要单独列出处理规则和审批人。同名人员依靠工号或唯一标识区分，不能只靠姓名匹配。多部门兼职要明确主部门与兼职部门在权限上的差异，避免两边都获得完整可见范围。外部人员、实习生和外包人员的账号有效期与归属部门也要写清，通常需要设置到期自动停用。每条例外规则都应指定审批人，否则例外会变成默认做法。
任务通知边界：触发条件、接收对象与通知粒度
通知规则的目标是让该知道的人及时知道，同时让不相关的人不被打扰。实现方式是把触发条件、接收对象和通知粒度三者分开配置，而不是为每个场景单独写一条“给某人发消息”的规则。
触发条件按工作项类型和状态流转定义。例如需求类工作项进入“待评审”时通知评审角色，缺陷类工作项被指派时通知负责人，任务类工作项截止日期变更时通知负责人和关注人。字段变化是否触发通知要有取舍：优先级、截止日期、负责人这类影响协作的字段适合触发，描述文本的普通编辑通常只记录变更历史，不单独推送。
| 触发条件 | 接收角色 | 渠道 | 粒度 | 例外 |
|---|---|---|---|---|
| 工作项被指派 | 负责人 | 钉钉即时提醒 | 单条 | 免打扰时段内转为次日汇总 |
| 状态进入待评审 | 评审角色 | 钉钉加站内 | 单条 | 同一工作项短时间内重复流转合并 |
| 截止日期变更 | 负责人、关注人 | 站内 | 单条 | 由负责人本人修改时不通知本人 |
| 超时未处理 | 负责人及其上级角色 | 钉钉 | 升级提醒 | 休假状态按代理规则转交 |
| 每日进展 | 项目角色 | 钉钉 | 汇总摘要 | 可个人关闭 |
接收对象按角色配置，不按具体人配置。负责人、参与人、关注人、评审角色、项目管理员这些角色由工作项和组织关系推导出来，人员变动时接收人自动重算。按人硬编码的规则在转岗和离职后最容易失效，旧人员继续收到通知，新人员收不到，而且很难从配置里发现。
通知粒度要给出默认值和可关闭范围。即时提醒适合指派、评审、超时升级这类需要快速响应的动作；汇总摘要适合进展同步和统计类信息。渠道上区分仅站内、仅钉钉、两者同时，默认值由研发流程负责人确定，个人可以在允许范围内调整。免打扰规则按夜间和休假设置，休假期间的通知按代理规则转交，超时未处理的升级路径要写明升级对象和升级间隔。
在研发流程侧，工作项状态定义和通知触发规则通常在同一处维护。ONES 提供 API 接口用于与企业系统集成，并支持对接钉钉等第三方应用，可作为承载工作项状态流转与通知配置的研发平台一侧；钉钉对接的具体能力范围与配置前提，需以官方文档和实际环境确认。规则设计阶段先把触发清单定下来，再落到具体配置，能减少反复调整。
角色分工与交付物：谁定规则、谁维护、谁验收
边界规则需要三类角色共同评审，各自负责一段流程，避免规则写完无人维护。
| 角色 | 职责 | 主要交付物 |
|---|---|---|
| 接口或集成负责人 | 连接配置、字段映射、同步异常处理与重试 | 字段映射表、异常处理台账、同步日志说明 |
| 研发流程负责人 | 工作项类型与状态定义、通知触发规则、通知粒度默认值 | 通知触发清单、状态流转说明 |
| 钉钉管理员 | 组织架构维护、应用可见范围、权限与通讯录字段管理 | 组织字段清单、可见范围配置记录 |
三类角色共同产出的交付物包括边界规则文档、变更记录和异常处理台账。边界规则文档记录字段清单、通知清单和责任划分，每次修改都要版本化并注明生效日期。变更记录用于回答“某条通知规则什么时候改的、谁批准的”。异常处理台账记录同步失败、通知错发、接收人错误等问题，写明发现时间、影响范围、处理人和关闭状态。台账是判断规则是否真正可运行的依据，没有台账，检查只能停留在文档层面。
评审节奏可以按变更类型区分：字段增减和主数据归属调整需要三方共同评审；通知触发条件的微调由研发流程负责人确认后记录；组织字段的展示调整由钉钉管理员处理并同步给另外两方。这样既保证关键变更有人把关，也避免所有调整都走长流程。
示例：一次转岗如何同时走通同步与通知
以下为演示情景，用于说明两类边界如何配合，不代表真实实施案例。
输入：某研发人员从 A 部门转到 B 部门，同时从项目甲的项目角色调整为项目乙的评审角色。人事系统发起转岗流程，审批通过并确定生效日期。
同步动作：集成任务读取转岗结果，更新部门归属和角色标识，写入钉钉通讯录，输出同步结果和生效时间。同步完成后核对：新部门可见范围是否包含该人员，原部门权限是否按规则收回，账号状态保持启用。
通知动作：研发平台按新的部门与角色关系重算接收人。项目甲中该人员的旧角色停止接收通知，项目乙的评审角色开始接收待评审提醒。输出通知规则变更记录，写明变更前后的接收角色和生效时间。
完成标志：新部门可见、旧通知停止、异常台账无未处理项。三项都满足，才算这次转岗在两类边界上都走通。离职场景同理：同步侧停用账号并收回归属，通知侧停止全部接收规则，代理规则按需转交未完成事项。
上线前的完成检查
边界定义是否可交付，可以按下面的清单逐项核对。每项都要有明确的责任人和可查的记录。
- 组织同步字段清单与任务通知触发清单均已评审，并有版本号和生效日期。
- 每个同步字段的主数据归属唯一，接收侧的手工修改入口已关闭或纳入审批。
- 入职、转岗、离职三类场景的生效时点和延迟容忍度已写明。
- 通知接收对象按角色配置，抽查若干工作项能正确推导出接收人。
- 免打扰、休假代理和超时升级规则已配置，并有对应的例外说明。
- 异常处理有责任人和台账，同步失败与通知错发都有回退或补发方式。
- 变更记录可追溯，最近一次规则调整能查到评审人和生效时间。
出现以下情况应判定为阻断项，先修正再上线：主数据两侧都可修改且无审批；通知接收人按具体人硬编码；没有异常处理台账；离职或转岗场景未验证接收人切换。阻断项不解决，规则文档写得再完整，运行后也会迅速偏离。
常见问题
组织同步的主数据为什么建议只保留一侧可改？
两侧都能修改时，同名人员、部门调整和离职停用会出现互相覆盖，出问题后很难判断哪条记录是准的。常见做法是以人事系统为主数据来源，钉钉通讯录作为接收侧，研发平台从同步结果中读取人员与部门关系。接收侧应关闭对应字段的手工编辑入口，或者至少建立变更审批，让绕过规则的修改留下记录。
转岗期间，旧部门的权限和旧角色的通知应该什么时候停？
以转岗生效日期为界。同步侧在生效日更新部门归属和角色标识，并核对原部门权限是否按规则收回；通知侧按新的角色关系重算接收人，旧角色停止接收，新角色开始接收。生效日之前仍按原归属处理，避免出现两边都收不到通知的空档。延迟容忍度要提前写明，例如“生效当日完成，最长不超过一个工作日”。
通知规则已经按角色配置，为什么还会出现错发？
常见原因有三类：一是角色与组织关系的推导规则本身有歧义，比如多部门兼职人员被同时算作两个项目的负责人；二是例外规则没有指定审批人，临时加人逐渐变成默认做法；三是免打扰和休假代理没有配置，升级提醒发给了不在岗的人。排查时先看接收人是怎么推导出来的，再看例外记录，最后核对代理规则是否生效。
ONES 在钉钉对接中能承担哪部分工作？
ONES 提供 API 接口用于与企业系统集成，并支持对接钉钉等第三方应用，可以作为承载工作项状态流转与通知配置的研发平台一侧。钉钉对接的具体能力范围与配置前提，需以官方文档和实际环境确认。边界规则本身属于方法层面，先定清单再落到具体配置，能减少反复调整。
规则上线后由谁维护，多久复核一次？
按变更类型分工：字段增减和主数据归属调整由三方共同评审；通知触发条件的微调由研发流程负责人确认后记录；组织字段的展示调整由钉钉管理员处理并同步给另外两方。复核节奏可以跟随组织调整和人员流动，例如每次大规模转岗或季度组织变更后，抽查接收人推导和同步结果，并更新异常台账。
