企业微信审批流和内部OA并存，出问题的地方往往不在审批引擎本身，而在两侧对“这个人是谁、归哪个部门、能批多大额度”的判断不一致。排查顺序建议先对齐身份，再对齐组织与权限，最后才动流程。下面按场景给出三种可选方案，以及各自不该选的情形。
先定位冲突：权限判断发生在哪一层
并列的审批系统，通常有四种冲突形态，先归类比直接改配置更省事。
- 身份层：同一个员工在企业微信和OA里是不同的账号记录，缺少稳定映射，审批人识别不出来或认错人。
- 组织层：部门、岗位、上下级关系在两边不同步，导致按部门找审批人时指向过期节点。
- 权限层：企业微信侧用可见范围控制能发起什么，OA侧用角色与数据权限控制能看什么，两个口径同时生效就出现“能提交、看不到、批不了”。
- 流程层：同一张单据在两边各有一套条件分支，金额、假期天数等判断标准不一致，会签与或签规则也不同。
归类的办法很简单：拿一条真实被卡住的单据，把“发起人账号、审批人账号、所属部门、当前节点”这四项在两边各查一遍并记录。四项中有几项对不上，冲突就落在对应层。建议固定一张排查单，逐条注明是账号问题还是节点问题，避免一边改一边猜。
方案一：以企业微信为统一入口，OA 退到后端
员工只在企业微信里发起和审批，OA 保留表单引擎、流程引擎与归档能力，通过接口交互，不再作为独立界面暴露给普通用户。这是目前政企客户里比较常见的做法，尤其适合移动办公比例高的场景。
- 优点：账号只有一个来源，减少重复登录与身份错配；移动端审批体验统一，催办与提醒集中在一处。
- 优点：与ERP、HR、财务等系统的对接可收敛到侧侧一次，已有封装可减少实施工作量。
- 缺点：对企业微信接口的可用性有依赖，侧侧停服时需有降级入口；历史审批数据的界面呈现要在OA中另做保留入口。
- 缺点：原有OA客户端用户的操作习惯要重新培训，流程表单字段如与OA原生控件强耦合，需做一层适配。
这种路线的工程重点在接口稳定性与降级预案，而不在流程设计本身。像软件定制开发与系统集成服务里涉及的账号映射、消息回调与节点同步，通常要单独列一张接口清单来管。我们做过的互联网与软件行业项目案例里，就有移动入口与内部管理系统并存的情形，可作参照。
方案二：以 OA 为主，企业微信只做消息与轻审批
权限、角色、数据范围一律由OA决定，企业微信侧只承载消息推送和简单的同意/驳回操作，复杂表单仍需回到OA处理。稳妥，但移动端体验的打磨空间有限。
- 优点：权限只有一个判定源，管理员不需要在两个后台维护同一套角色；历史配置改动小，上线风险低。
- 优点：适合审批链条长、表单复杂、与财务和合同强关联的场景，归档与审计统一在OA侧完成。
- 缺点：企业微信端功能受限，审批人遇到需要看附件明细或补录字段时仍要跳转，移动办公闭环不完整。
- 缺点：两套组织架构仍需周期性对账，一旦人员调动未及时同步，待办仍会落到旧节点。
判断标准是看移动端处理的单据是否以“看一眼就能批”为主。如果超过一步需要查明细、填补充说明，这条路线的体验损失会一直存在。交付阶段建议先按服务范围与交付流程做小范围试点，再决定推广节奏。
方案三：统一账号与统一权限目录（SSO 加组织映射）
两边各自保留独立界面，但账号、组织与角色映射统一到一套目录服务，企业微信与OA都从这里读取身份和上下级关系。这是介于前两者之间的中间路线，改造点集中在身份层。
- 优点：不推翻现有使用习惯，两侧仍可独立演进；权限判定逻辑集中到一个地方，排查有据可依。
- 优点：工程投入主要落在组织同步与角色对照上，不涉及大批业务页面重写。
- 缺点：映射规则一旦有例外人员（兼职、外派、临时项目组），需要人工兜底，运维负担随之上升。
- 缺点：映射失效时问题隐性强，往往表现为“某个人批不了”而非系统报错，监控要专门覆盖。
这条路线适合既有工具不宜替换、但组织变动频繁的企业。国产 OA（泛微、致远等）的实施与二次开发中，组织与权限体系梳理本身就是工作量较大的环节；若走统一目录，建议把规则写入交付文档并配备定期校验任务。具体改造方式可参考同类项目案例中组织同步的做法。
什么情况下不要选这几种方案
不要选“企业微信为统一入口”的情形：内部审批涉及较多离线场景、厂区或外网访问受限；或者OA承载着必须留在内网的合同、财务流程，移动端接口开通受限。
不要选“OA为主、微信只做消息”的情形：一线员工绝大多数时间在手机上办公，审批多为移动场景；或者企业微信侧已形成较完整的业务流程，退回OA会打断既有使用习惯。
不要选“统一目录映射”的情形：两边都没有稳定的人员编码可用、组织数据本身混乱。此时先做组织与账号的基础治理，上映射只会把错误固化下来。
另外两种情形单独说明：若冲突只集中在少数几个审批节点，优先定位配置而不是改架构；若审批流程和业务规则本身还没梳理清楚，任何技术统一方案都只是把混乱从两边搬到一处。拿不准时，可参考政府与国企国产化改造案例里的实施顺序：先稳定身份、再梳理权限、最后收拢流程。
自查清单与落地步骤
下列步骤建议按顺序执行，每一步都有可验证的结果。
- 导出两边的人员账号表，按工号或手机号核对，标出无对应关系的人。
- 绘制部门与上下级关系对照图，检查审批节点引用的组织路径是否仍然有效。
- 抽取一条被卡单据，记录两边对发起权限、审批权的判定结果，差异点写入排查单。
- 确认角色口径：谁是系统管理员、谁是流程管理员、谁是数据权限审批人，避免职责重叠。
- 选择统一方案，明确哪一侧是权限判定的主源，另一侧只做展示或仅处理特定场景。
- 梳理异常处理：账号停用后待办如何处理、人员调动后的节点重定向规则、接口异常的兜底入口。
- 上线前做对账验证，覆盖临退休、兼职、外包等边缘人员，并把验证结果作为验收材料归档。
- 上线后设置周期性核对任务，发现节点或权限漂移及时修正，形成稳定的交付后维护机制。
对比清单如下，供选型会上逐条确认：方案一（企业微信为入口）适合移动办公比例高的企业，主要代价是接口依赖与培训；方案二（OA为主）适合审批链复杂、重归档的场景，主要代价是移动端体验与组织定期对账；方案三（统一目录映射）适合保留现有界面但组织变动频繁的情形，主要代价是映射维护与隐性故障监控。选择时先问一句：哪一侧能稳定拿得准人和组织，就把权限主源放在哪一侧。
