Skip to main content

用户同步-概述

用户同步从企业通讯录维护千问办公的部门、成员与关系。同步通过三方 ID 查找用户,成功写入后由该来源维护用户资料;入职、调岗和离职按来源策略更新到千问办公。它不决定成员的登录方式;企业 SSO 需要在身份认证中配置。

用户同步从企业通讯录维护千问办公的部门、成员与关系。同步通过三方 ID 查找用户,成功写入后由该来源维护用户资料;入职、调岗和离职按来源策略更新到千问办公。它不决定成员的登录方式;企业 SSO 需要在身份认证中配置。

选择同步方式

进入 用户与体验 → 用户管理 → 用户同步,点击【新增数据源】,选择实际来源。可按来源选择相应配置:
来源适用情况操作路径
钉钉从钉钉企业通讯录读取成员和部门用户管理 → 用户同步 → 钉钉
飞书从飞书企业通讯录读取组织架构用户管理 → 用户同步 → 飞书
企业微信从企业微信读取成员、部门和关系用户管理 → 用户同步 → 企业微信用户同步
Windows AD从 Windows 域目录读取用户和部门用户管理 → 用户同步 → Windows AD
OpenLDAP从 LDAP 目录按字段映射读取条目用户管理 → 用户同步 → OpenLDAP
Microsoft Entra ID使用企业租户应用读取目录用户管理 → 用户同步 → Microsoft Entra ID
SCIM由身份平台主动向千问办公推送成员变化用户管理 → 用户同步 → SCIM

配置前先决定三件事

配置前,请先确定:
  1. 同步范围: 哪些部门和成员需要进入千问办公。
  2. 身份标识: 用哪个稳定字段持续识别同一用户。
  3. 离职处理: 成员离职后,停用还是删除账号。
三方平台中的应用权限必须覆盖准备同步的完整组织结构和必要上级部门。不要为了测试而把三方应用只限制到一个小部门:读取不完整会让千问办公无法判断完整的部门层级,也可能把本应存在的成员判断为不在范围内。需要分批接入时,在千问办公的同步策略中选择「指定部门及后代」。 注意: 企业同一时间只启用一个同步来源。切换前须核对原有成员的身份关联。 除 SCIM 外,配置窗口依次为「应用凭证」「设置字段映射」「设置同步策略」。点击【测试并下一步】时,系统先检查连接;新建数据源时,成功后保存当前配置草稿:钉钉、飞书、企业微信和 Entra ID 只交换访问令牌,Windows AD 和 OpenLDAP 检查目录地址与绑定。该步骤不会枚举部门或成员,也不能证明平台权限、字段和组织范围正确。映射决定每个来源字段写到哪里;策略决定范围、执行时间和删除处理。SCIM 则由外部身份平台调用本企业的 Base URL。 企业微信填写回调密钥后,先点击【保存回调配置】,取得消息接收 URL 并在企业微信后台完成验证、配置企业可信 IP,再返回点击【测试并下一步】。保存回调配置仅保存草稿,不代表连接已通过或同步已完成;消息接收不触发通讯录实时更新。

确认启用或停用结果

启用、停用或切换数据源后,先查看页面显示的当前状态。出现「结果待确认」时,操作可能已提交,但系统尚未取得最终状态。点击【重新确认】只查询最新结果,不会再次提交启停操作。确认期间不要重复切换来源;刷新失败时保留提示,待连接恢复后再次确认。只有页面显示最终状态后,才能据此安排下一次同步。

执行后核对结果

  1. 在同步策略中设置范围:钉钉、飞书、企业微信和 Entra ID 选择全部或指定部门;AD 和 OpenLDAP 通过 Base DN 及用户、部门过滤器限定范围。读取型数据源支持仅手动或定时同步,定时方式每天在所选北京时间执行一次。
  2. 保存数据源配置并确认启用状态。
  3. 在同步记录中按数据源、触发方式、结果和日期筛选,打开【详情】。
  4. 分别核对用户、部门、成员关系和席位变化。出现「部分成功」时,查看失败对象与原因,修正后再执行。
  5. 进入「用户」页,检查一名新增成员、一名调岗成员及一名离职成员,确认部门、状态和席位符合预期。
管理后台:按任务核对同步结果和用户变化。

查看同步记录中的具体变更

在同步记录中找到目标任务,打开详情并按用户或部门查看结果。除了成功、失败或跳过,还应核对实际变更字段和原因,例如部门调整、绑定变化或同步来源变化。 没有变化的对象不会作为一次新增变更反复展示。历史记录可能没有记录完整字段差异;页面提示未记录时,应结合该次任务的其他信息核对,不能把当前用户资料当作当时的修改内容。 发现失败时,记录对象标识和具体原因,在来源系统或字段映射中修正后再同步。不要仅凭任务总体成功就认定每个对象都已完成预期变更。
管理后台:核对李思远的变更字段、原因及调入调出部门。

修改范围与离职处理

编辑已有数据源时点击【修改配置】,重新检查字段映射和删除处理后保存。缩小范围可能使原先同步的成员离开同步范围,因此不要只修改部门勾选而忽略离职策略。 注意: 删除数量达到设置的阈值时记录告警,管理员应在同步记录中检查结果。同步不会因此等待人工审批,仍按已配置的删除处理规则执行。

已有用户如何接入同步

同步只用非空的三方 ID 查找用户,不以账号、邮箱、手机号或工号认领已有用户。三方 ID 全局唯一,不与同步源的来源 ID 拼成匹配条件。账号、邮箱、手机号、工号在未删除用户中分别唯一,停用用户仍占用这些值。
情况处理结果
三方 ID 命中未删除用户更新该 QID 的映射字段,成功后将当前维护来源切换为本次同步源
三方 ID 未命中,账号、邮箱、手机号、工号也无冲突通过公共校验后新增用户
三方 ID 未命中,但账号、邮箱、手机号或工号已被占用本条失败;管理员在原用户上补齐或修正三方 ID 后重试
三方 ID 命中,但账号、邮箱、手机号或工号属于另一用户本条失败,原资料、来源和席位均不改变
对于先手动新增或导入的用户,先在原用户上维护正确三方 ID,再执行同步。不要新建一条同邮箱用户来代替已有成员。

哪些字段由同步维护

用户的维护来源与当前已开启的同步来源一致时,按下表锁定字段。其他来源用户可按权限编辑。
字段后台、导入更新和通用 API 的修改规则
姓名、邮箱、账号、手机号、三方 ID、工号均由来源维护,不可修改;移除映射也不会解锁
部门、状态配置了映射时锁定;移除映射后恢复编辑
注意: 开启用户同步期间,整个组织禁止手动新增、邀请、导入新增和删除用户。导入更新仍可使用,但必须遵守字段锁定规则。

添加或调整映射

  1. 在对应映射区域打开【添加映射】,选择尚未映射的千问办公字段。
  2. 页面添加一行,并带入预设来源。右侧目标字段固定;成员映射可从该数据源支持的字段中选择左侧来源;部门映射通常使用预设来源。
  3. 核对必填映射。必填行不可删除,可选行可以删除后重新添加;打开配置不会自动改写已有保存值。
  4. 保存配置后,重新执行同步,并核对目标用户的 QID 和字段值。
保存后的影响:
  • 新增映射后,目标字段立即由同步维护;移除部门或状态映射后,这两项恢复编辑。
  • 移除映射不会清空已有值,也不会解锁六项基本资料。
  • 修改三方 ID 映射可能命中另一用户或创建新 QID,须由管理员确认对应关系。
  • 尚未提交的旧版本任务会失败,需要重新执行。

删除后再次出现与换源

用户被删除后,旧 QID 和旧资料不会恢复。账号、邮箱、手机号和工号可以被其他用户复用;旧同步历史仍保留,便于管理员追溯。 拉取型数据源再次返回同一成员时,系统按以下规则处理:
情况处理结果
三方 ID 命中未删除用户更新原 QID;成功后将该用户的维护来源切换为本次同步源
三方 ID 只命中已删除记录按本次来源资料创建新用户和新 QID,并记为“创建”;三方 ID 改为关联新用户,旧历史不改写
新账号、邮箱、手机号或工号与在用用户冲突本条失败;系统不会覆盖已有用户,须先修改来源资料或映射后重试
新建的账号不会继承旧账号的角色、密码、用户组、管理员权限、席位或部门。默认席位按当前数据源的“新用户默认申请席位”设置处理,部门按本次同步结果写入。 SSO 使用自己的“自动创建用户”开关:关闭时登录失败;开启且资料无冲突时创建新用户和新 QID。SCIM 删除资源后不能继续更新原资源,身份平台须重新创建 User,系统会分配新 QID。两种方式都不会恢复旧 QID。 从来源 A 切换到 B 时,未删除用户可由 B 使用相同三方 ID 更新,成功后保留原 QID 并改由 B 维护。用户已经删除时没有“先恢复再换源”的步骤;应由计划长期使用的来源重新同步并创建新用户。 ℹ️ 说明: 删除后重新创建的数据源会获得新的来源 ID,不等同于原来源。

处理失败记录

一名用户出现冲突时,其资料、来源和关系整条不写入;其他独立有效用户可以成功。同步记录显示失败对象和字段。上游读取失败、范围不完整或同批身份冲突时,不会把无法确认的缺失用户作为离职对象。修正来源资料后重新执行,并回到用户列表核对 QID 和最终字段。

部门目标无效时如何处理

身份唯一字段冲突与部门目标无效的处理不同,请按同步记录中的具体原因判断。
  • 已有用户:目标部门无效时,保留原有的完整部门关系和主部门;其他合法资料仍可能更新。
  • 新用户:所有目标部门均无效时,不创建该成员账号或身份关联,并记录失败;部分有效时,只建立有效部门关系,同时记录无效目标。
  • 部门数量超过上限:按最终有效部门集合去重计算,单个用户最多 200 个,包含仍需保留的手动、范围外及根部门关系。超过上限时本批次回滚,不会截取前 200 个写入。
例如李思远原属产品研发部,目标部门无效时,原部门关系应保留。请同时核对资料更新记录和部门结果,修正来源部门或同步范围后再执行。不要将某个部门失败等同于所有用户都未更新。