了解策略顺序

通过指定策略的执行顺序,可以为审批和最终提交策略分配优先级。批准或最终提交请求时,具有相同顺序的策略将作为一个组来执行,然后再转到下一个组。

例如,您可以分配策略顺序,以便在审批策略之前执行扩充策略,或者在维策略之前强制执行节点类型策略。

在审批或最终提交策略的“定义”选项卡上指定策略顺序。(请参阅“创建和启用审批策略”)。

策略顺序处理

具有多个策略的请求进入审批或最终提交阶段时,将进行以下处理:

  1. 对于策略顺序具有最低顺序(例如 1)的所有策略,审批(或最终提交,在最终提交阶段)将作为一个组进行处理。批准(或最终提交)邀请将发送给组合在一起的所有策略中的所有受邀请者。
  2. 执行了具有最低策略顺序的所有策略后,具有下一个最高顺序策略顺序(例如 2)的策略将作为一个组进行处理。邀请将发送给当前组中的所有受邀请者,以及任何先前组中的任何未执行策略(以说明在处理请求时将未执行的策略修改为较低数字)。

    Note:

    如果当前受邀请者已在策略顺序中较早提供了审批或最终提交,则该用户将为其在当前组中的每个策略进行自动批准。
  3. 按策略顺序编号分组处理策略,直到没有未执行的策略。
  4. 请求移动到下一个阶段(例如,如果请求处于审批阶段,并且存在最终提交策略,则请求移动到最终提交阶段)。
  5. 最终提交阶段中具有最低编号策略顺序的策略将作为一个组进行处理,依此类推。
  6. 没有剩余阶段时,将尝试完成并关闭请求。

请求扩充和策略顺序

如果以激活策略的方式扩充请求,则新策略将根据其策略顺序包含在下一个工作流周期中。换句话说,如果使用比当前组更早的组中的策略所影响的数据扩充请求(例如,最初未激活的策略或已批准的策略),则会邀请较早组中所有策略的受邀请者与当前组中的受邀请者一起批准请求。

例如,假设您有三组策略,顺序为 1、2 和 3:

  1. 提交的请求包含受组 1 和组 3 中的策略影响、但不受组 2 中的策略影响的数据。
  2. 执行组 1 中的策略,但是处理组 3 期间,将扩充请求以包含受组 2 中的策略影响的数据。
  3. 组 2 中的受邀请者与组 3 中的当前受邀请者一起包括在内。现在必须执行组 2 和 3 中的所有策略,然后才能将请求转换到下一个阶段。

请求退回、撤回以及撤消审批

按如下所示处理由于退回、撤回以及撤消审批而导致的请求阶段变更:

  • 对于请求退回或撤回,将清除所有审批。请求再次进入审批或最终提交阶段时,策略顺序将以最低顺序重新开始。
  • 撤消对请求的审批时,将保留在撤消的审批之前发生的审批,并清除在撤消的审批之后发生的审批。例如,如果在策略组顺序 2 中撤消了审批,则保留策略组顺序 1 中的审批,并清除策略组顺序 3 中的审批。

    对于与撤消的审批位于同一策略组中的审批:

    • 如果撤消的审批位于顺序策略中,则清除撤消的审批之后的审批。
    • 保留顺序策略中撤消的审批之前的审批以及并行策略中的所有审批。

查看策略执行计划

请求检查器的“策略”选项卡显示请求中策略的执行计划。请参阅“策略执行计划”。