审批发起人：
需要完成的主要是事务性、操作性的工作，同时也是一个审批流程的Owner，是最关心审批进展的人。因此在发起人的角度，
1、创建审批事项
2、还需要完善相关信息
3、催促审批人及时审批
4、处理驳回修改意见
5、重新提交、撤回。
6、查看审批纪录等。
审批审核人：
查看最重要的信息，避免信息过多影响判断审批操作和管理(通过、驳回、加签，转移)，加签：添加他人审批，审批之后我再审批；转移：直接转给他人审批审批历史，以便追溯
常见审批流程
1、串行
逐级通过审批才算完成、在审批流程中时，可配置发起人操作权限(如撤回)！
2、并行
2.1：任一级完成进入下一流程
2.2：同一层级审核完进入下一流程
任意一个审批人驳回，流程结束！
3、条件
审批流程中的操作说明
1. 通过
通过动作由审批人操作，是否需要输入通过描述(便于追溯)、是否必填需要根据实际业务情况决定。要点总结如下：
简单申请不需要填写通过描述，或者选填通过描述需要填的话，可用于反馈或激励发起人的情况、追溯审批流程
2. 驳回(修改)
驳回修改动作由审批人操作，和通过不同，为了让发起人知道如何修改，驳回原因一般需要设定成必填项，否则发起人或上一个审批环节的人不知道为何被驳回、以及要如何修改。
驳回修改可根据业务需要，在以下逻辑中选择：
驳回到发起人驳回上一环节驳回到选定的之前的某个审批环节
3. 重新提交
重新提交由发起人操作，和驳回修改是一一对应的。设计上要注意，审批人审批重新提交的内容时，需要附带上一次驳回修改的原因。
4. 取消
取消动作可选，一般来说是发起人取消，而不是审批人取消，原因如下：
审批人只关心一个审批事务过来后，判断并决策是通过还是驳回取消和驳回含义容易混淆，区分不开
在设计上，发起人是否可取消可由配置项进行配置。
5. 加签
加签动作可选，一般来说是审批人加签，原因如下：
审批人只关心一个审批事务过来后，判断并决策是通过还是驳回不清晰发起人的信息需要其他人员的审批之后才可确认
在设计上，是否加签可由配置项进行配置。
6. 转移
转移动作可选，一般来说是审批人操作，原因如下：
审批人看到了信息，但是自己无暇处理，转移给其他人尽心细节查看和审批
视业务场景，由配置项进行配置。
7. 其他
考虑到流程过程中审批人账号注销的情况，可能导致整个流程不能及时处理！
流程结束后，修改流程！ 如钉钉，流程审批结束后，最初的审核信息调整为实际情况，修改审批流程，重新发起，由原路审批人审批！
方案：
7.1：设计超管账户进行替代当前流程审批人的审批
7.2：系统及时通知发起人撤回，或者强制退回
7.3：有问题的由系统审核退回(业务场景如：引用他人数据，他人数据修改，自己的必须与引用数据保持一致)
总结：
以上是工作流常见的操作、流程！灵活的流程能够更好的体现审批效率，做好设计、代码侵入少且适用性强的流程是首选的！
