基本原则

审批场景是B端中后台业务场景中的一个特殊分支，融合了表单页、详情页等多个页面形态的特质，使用频率高、用户层级高、设计难度高。设计者需要基于原子设计理念，梳理和整合数据信息，按每个角色对不同事项的关注层级，构建科学规范的设计系统。

设计分析

用户群体分析

• 提报人：填写单据，提交审批
• 审批人：审核单据，进行决策
• 审批管理员：管理审批模版、配置审批流程、设置节点等

日常审批存在的问题

• 不会填——不理解怎么填、不明白要填什么、不清楚要写的内容方向是什么
• 不会用——操作复杂无从下手、交互随性颠覆认知
• 找不到——无法快速看到重点审批内容、无法快速找到操作按钮的位置

评价和准出原则

审批场景是企业内部最重要的交互场景之一，集团内任何形态、开发路径、业务领域的信息化产品都需要遵循本规范。

本规范更关注的是交互层面的一致性和规范性，原则上接受因技术栈差异导致的视觉细节差异，但是如果可能，仍然推荐使用统一的审批页模板来设计和实现。

设计原则

好的填单、审批体验来自合理的表单元素和填写流程，合理运用页面构成元素，用适当的错误提示、即时校验等交互方式帮助用户理解表单内容，快速填写，从而提高审批效率。鉴于以上，整个审批页的设计过程需遵循如下原则：

• 信息传达准确：能有效并准确传达审批流的相关信息。
• 流程操作高效：能提升组织内部的运转效率。
• 节点可预知：能帮助各角色提前了解审批流程。
• 历史可回溯：对已结束的审批单据能随时回溯。

审批人设置原则

1. 审批节点的审批人需要基于岗位或角色来确定，不允许在流程运转过程中由当前处理人手动选择后续节点的审批人；
2. 同一流程中各节点的审批人不允许全部设置为同一个人；
3. 财务、人资等业务领域中如存在与流程相关的规定要求，流程负责人需要基于对应规定做好各角色之间的互斥设计；

自动审批原则

1. 流程设计时需要考虑自动审批规则，包括：
   • 发起人自动审批（当前节点人员为发起人时，自动审批）
   • 相邻节点自动审批（当前节点人员为上一节点人员时，自动审批）
   • 审批人自动去重（审批人重复出现时，只需审批一次其余自动通过，使用该规则的前提是当前节点没有可编辑的审批内容字段）
2. 当前节点存在需要审批人录入的表单数据时，不允许开启系统自动审批；

设计规范

审批页的设计规范可参考各自终端对应典型页面的要求。由于审批场景包含「流程发起、流程审批」2个角色场景，其中流程发起场景的形态并不固定（以表单页居多），因此规范中主要面向流程审批场景对应的「流程审批页」进行描述和约定。

名词定义

为了保证集团内所有审批页场景中操作的一致性，遵循交互体验表述一致原则，我们对审批页中各操作的定义、文案进行了约定，减少用户理解成本。

备注

部分业务场景中可能会存在特殊的操作，可基于系统一致性原则自行定义。

常规操作

操作	定义
提交	发起人发起审批或审批人将处理意见完成提交。
暂存	在流程发起或审批过程中将当前填写的表单/单据数据保存下来，但并不触发数据的校验和流程节点的运转。 暂存的数据并非正式生效的数据，只允许操作人自己可见，在正式提交后才被其他相关人可见。
传阅	将当前审批页分享给其他用户查看，查看的数据权限继承操作人的数据权限。
打印	将当前审批流程页面中的数据基于打印模版打印。

审批操作

为了尽可能方便理解，本表格的顺序不代表最终操作按钮的展示顺序，展示顺序以3.2布局框架中的描述为准。

操作	定义	默认处理意见
通过	当前审批人认同审批内容，提交后流程将流向下一节点	同意
不通过	当前审批人不认同审批内容，且不需要让流程相关人进行调整，提交后流程将结束或终止
同意	仅会签节点存在，仅代表当前审批人的同意态度，并根据当前流程的会签规则进行流转。	同意
不同意	仅会签节点存在，仅代表当前审批人的不同意态度，并根据当前流程的会签规则进行流转。
驳回	当前审批人将该条流程退回到某个前序节点，但不影响流程的正常运转。驳回时须支持操作人选择驳回目标节点，建议支持操作人选择驳回节点通过后的流转策略，流转策略可包括以下2种： 1. 按顺序流转 被驳回的节点重新提交时，按照当前的流程顺序流转。 2. 返回这个节点所有人 被驳回的节点重新提交时，跳过中间的其他节点，直接流转至本节点。 - 当被驳回的节点重新执行「提交、批量提交」时，跳过全部节点及流转条件，直接流转至当前节点； - 当被回退的节点重新执行「暂存、转办、加签」时，流程暂不流转； - 当被回退的节点重新执行「驳回、不通过、废弃」时，不再直达当前节点。
沟通	当前节点处理人希望与某个相关人进行意见交流，，提交后当前流程将由审批状态切换为沟通状态，整个沟通过程中流程停留在当前节点
回复沟通	当前节点处理人希望与某个相关人进行意见交流，，提交后当前流程将由审批状态切换为沟通状态，整个沟通过程中流程停留在当前节点
取消沟通	沟通发起人认为沟通已无必要，提交后当前流程将由沟通状态切换为审批状态
转办	将该流程转交给其他成员进行处理，即更换当前节点的处理人，转办仅支持选择1个转办对象
加签	当前节点的处理人难以准确判断或需要额外的审批意见，需要在当前节点中添加其他人作为审批人的操作，加签可提供前加签、后加签2种方式： - 前加签：选择前加签并提交,当前处理任务消失,加签审批人收到任务，全部加签审批人处理完任务后,任务回到当前处理人这里； - 后加签：选择后加签并提交，默认为当前处理人执行通过操作,流程会到加签审批人处，并正常流转。加签审批人如果选择驳回,则任务回到当前处理人处。

发起人操作

操作	定义
催办	前序节点处理人催促当前节点处理人尽快处理流程审批，系统通过邮件、信鸿待办方式提醒当前节点处理人。
撤回	发起人将进行中的流程撤回到发起节点的草稿状态
废弃	发起人在流程被驳回或主动撤回到发起节点的情况下，可主动废弃当前流程

布局框架

• PC审批页
• 移动审批页

页面跳转

PC及移动审批页在完成提交、审批处理等操作后，需要以轻提示的方式告知用户操作结果，并在告知用户结果不少于 1 秒后跳转至合适的列表页或关闭当前页面。

推荐使用 Message 或 Toast 组件来进行结果的反馈。

人员选择器

审批页有大量人员、部门选择的场景，各系统需要为用户提供良好、一致的选择体验。在人员/部门选择器中，需要支持以下能力：

1. 搜索——支持通过「姓名、账号、工号」等字段进行全局查询，查询结果至少需要包括「姓名、账号、部门」几个字段的呈现
2. 选择列表——支持基于下表的维度进行快速选择

顺序	选择维度	定义及数据范围	是否必须
1	最近	近期在选择器中进行过选择、查询的人员	✓
2	流程相关人	当前流程前序节点的所有处理人（含发起、被沟通、被转办人员），按操作时问倒序排列，不显示机器人账号	仅审批操作区必须
3	组织架构	基于LDAP组织按层级展开的树状列表，默认展开到当前用户所在组织层级	✓
4	群组	以业务场景建立的人员群组

待办通知

流程审批过程中的各个关键节点以及流程结束后，都需要向相关人发送待办通知进行告知，发送渠道可以是邮件、信鸿待办、门户待办，建议通过三合一待办接口同时支持三种。

标题格式

待办通知的标题，需要参照统一的格式规范要求，包含如下字段信息：

字段名称	示例	备注
处理类型	请审批、请处理…	并非所有的待办都是引导用户进行审批操作，因此需要基于不同的情况添加不同的前缀
发起人所在部门	流程IT与数据管理部	这里并非指组织全路径，而是LDAP中定义的某个层级的部门名称
发起人姓名	张三
流程名称	外协人员一卡通门禁开通申请	流程名称在部分系统中可能叫标题或主题，有的流程是用户手动录入，有的是系统基于某个格式拼接而成的
发起人所属公司	集团公司	非必须
发起时间	2023-01-01	非必须

注意事项

1. 由于流程名称的格式由各系统自己定义，可能已经包含了上表要求的字段信息，如果出现这种情况，就可以在待办发送时不再重复拼接相同的字段，即确保拼接后的结果中包含以上字段即可。
2. 标题的拼接可使用中括号、短横线、冒号等符号对字段进行间隔，方便用户阅读
3. 带有紧急程度功能的系统在标题中，需要将紧急状态放置在标题起始初，如：[紧急]

拼接格式参考

邮件内容

邮件内容需要支持与本系统一致的语言数量，比如本系统中支持简体中文、英文、日语，邮件内容也需要体现这三种语言。

邮件中需要明确展示出审批页的入口链接，且同样需要支持与本系统相同的多语言。下图为OA审批邮件内容示例：

权限控制

系统需要提供角色权限管理功能，确保不同角色、不同节点的用户在审批页只能进行其具备权限的操作，保障审批流程的安全性，尤其要避免非流程相关人通过链接分享的方式进入审批页的情况。