为了追求稳定的迭代，不希望一些激进策略的实验开启或全量上线影响到产品，有些场景希望Feature发布放量之前，增加审批的流程，以此减少由于误操作带来对线上的影响。另外一些更加重大的功能迭代，在发布上线前希望有更多诸如内测、小流量测试的环节保证发布安全性。
不过，引入审批等环节会增加Feature发布整体的流程，流程的增加势必会影响到灵活性；而诸如一些快速迭代的业务、紧急bugfix，则希望能够快速上线，不希望有更多流程的阻塞。
综合不同场景安全性和灵活性的诉求，我们将审批、内测等作为其中一个环节，支持不同的业务可置不同的工作流程(如Feature发布需要哪些环节，是否需要审批等)。
场景1：重要功能的Feature发布
某短视频APP计划引入直播功能，先开实验运行一段时间后得出效果显著的结论，计划将实验固化为Feature发布全量上线。不过上线直播功能是一个大的功能迭代，需要谨慎操作，故希望这类重要功能的实验固化需要经过业务线管理员审批，审批通过后再逐步灰度放量。
场景2：紧急bugfix的Feature发布
某APP的登录功能出现了闪退现象，经检查发现是有小bug，经过修复后在测试环境验证OK，想快速这个Feature发布全量，快速减少用户体验问题，需快速发布，不希望有审批等更多流程。

• 功能入口：【全局设置】-【工作流管理】-【流程设置】

• 

• 可在工作流程管理中，点击对应的流程，点击编辑，即可为该流程设置需要哪些环节

  • 确认Feature信息：系统默认步骤(默认打开，不可关闭)

  • 审批：可设置审批规则

    • 审批层级：

      • 1级审批(默认):即只有1层审批

    • 审批人

      • 设置默认审批人：角色（默认）、姓名/邮箱，可多选

      • 默认为应用管理员、集团管理员，支持管理员添加其他人为默认审批人

      • 允许自行添加：默认不勾选，若勾选，则单个任务在发起审批时可自行添加审批人

    • 通过机制：1人通过即通过(默认）、超过半数通过即通过、全部通过即通过

    • 驳回机制：驳回后可重新邀请(默认）、驳回后发布取消

    • 审批通知：审批状态变更时向相应人员（Owner、审批发起人、审批人）发送通知，可选飞书（邮箱、其他IM工具可以后续迭代时考虑），可多选

    • 默认打开，管理员可关闭该步骤