政策、审批和治理

政策控制您的组织中的操作是立即完成,还是必须先由其他成员批准。每个工作流都有其独立可配置的政策。本文将解释批准、政策和锁定如何协同工作。有关权限和工作流的结构,请参阅权限和工作流。如需概览,请参阅关于组织

批准如何运作

组织中的每项受控操作都遵循相同的生命周期:

步骤 1 — 启动: 具有启动或执行权限的成员创建请求。

步骤 2 — 立即完成检查: 如果成员持有执行权限且工作流不需要批准(“始终需要批准”为关闭状态),则请求会立即完成。没有批准队列,无需等待。

步骤 3 — 批准队列: 如果请求无法立即完成——无论是由于成员缺乏执行权限,还是由于“始终需要批准”为开启状态——请求将进入批准队列。拥有该工作流批准权限的成员可以对其进行审核。

步骤 4 — 批准阈值: 一旦达到所需数量的独立批准,请求即完成。

步骤 5 — 拒绝: 任何单独的审批者都可以拒绝待处理请求。被拒绝的请求不会完成。

职责分离

成员不能批准自己的请求。此规则由系统在所有工作流中强制执行,不能通过任何权限或政策配置来覆盖。

单个成员独立完成操作的唯一方式是通过执行权限,并且仅当工作流政策允许时。

执行权限与政策交互

执行权限与“始终需要批准”的政策设置交互:

成员权限

“始终需要审批”

会发生什么

发起 + 执行

关闭

请求立即完成,无需批准

发起 + 执行

开启

请求进入批准队列,必须等待独立审批者

当“始终需要批准”开启时,执行权限会怎样?

执行权限不会从成员那里移除。它在权限配置中仍然可见,但当“始终需要批准”为开启状态时,系统会忽略它。用户界面会在执行权限列上显示一个警告颜色指示器。如果您稍后将“始终需要批准”重新切换为关闭状态,则成员可以再次立即完成操作,而无需重新分配权限。

地址更改的电子邮件确认

当成员使用执行权限立即添加或移除白名单地址(无需独立审批者)时,系统会在更改生效前发送一封电子邮件确认。地址更改只有在确认完成后才会最终确定。

在测试阶段(Beta),电子邮件确认将发送给组织所有者,无论哪个成员启动了更改。直接将确认发送给请求创建者计划在未来版本中实现。

设备信任状态不影响此行为 — 即时地址更改始终需要电子邮件确认。

当地址更改请求通过独立审批人进行标准审批流程时,无需电子邮件确认。其他成员的批准可作为安全控制。

如何配置策略

  1. 转到您组织中的“管理策略”部分。
  2. 选择您要配置的工作流(例如,“发起提现”)。
  3. 设置所需的审批数量 — 这是在请求完成之前必须批准的拥有“批准”权限的独立成员数量。
  4. 选择是否启用“始终需要批准”。开启时,此工作流上的每个请求都必须经过审批队列,即使是拥有“执行”权限的成员。关闭时,拥有“执行”权限的成员可以立即完成操作。
  5. 审查配置并确认。

如果“管理策略”工作流本身已配置策略,您的更改可能会进入审批队列。有关策略治理工作原理的详细信息,请参阅“锁定策略”。

策略设置

每个工作流都有自己的策略,包含两个设置:

设置

作用

需要批准

在请求完成之前必须批准的独立审批人数量。审批人从拥有该工作流“批准”权限的成员池中选出。发起请求的人始终排除在审批人池之外。

始终需要审批

开启时:所有请求都必须经过审批,即使成员拥有“执行”权限。关闭时:拥有“执行”权限的成员可以立即完成操作。

锁定策略

策略锁定可防止任何单个成员(包括组织所有者)单独更改工作流的治理设置。

策略锁定后:

  • 对该工作流策略的任何更改都需要独立成员的批准
  • 解锁也需要独立批准
  • 所有者受与其他所有成员相同的规则约束

一旦治理被锁定,任何人都不能单独削弱它。未来仍可能进行更改,但这取决于独立的批准和审批人覆盖范围的可用性。

范围:策略锁定适用于每个工作流。锁定一个工作流的策略不会影响任何其他工作流。这使您能够逐步收紧治理,一次一个工作流。

策略锁定与“管理策略”中的“始终需要批准”

这两种控制在不同层面上服务于同一目标:

控制

范围

效果

策略锁定

一次一个工作流

对该特定工作流策略的更改需要独立批准。其他工作流不受影响。

在管理策略中“始终要求审批”

同时应用于所有工作流程

所有工作流程中的所有策略更改都需要独立审批。作为批量治理开关。

使用策略锁定进行逐步收紧。仅当您希望一次性治理所有策略更改时,才在管理策略中使用“始终要求审批”。

保障措施

系统实施保障措施,以防止无效或不可执行的配置:

审批人可用性:除非至少有一名其他成员(除了锁定人)在管理策略工作流程中拥有“批准”权限,否则策略无法锁定。否则,锁定的策略可能导致僵局,没有人可以批准未来的更改。

锁定预防:当工作流程中唯一拥有“批准”权限的成员也拥有“发起”权限,且所需的批准数量为 1 时,系统会阻止保存策略。由于成员无法批准自己的请求,因此该成员的请求将没有符合条件的审批人。

停用不检查审批人覆盖范围:目前,即使停用或移除成员会将可用审批人的数量减少到工作流程所需阈值以下,此操作仍会继续。停用的自动覆盖范围检查计划在未来版本中推出。在此之前,在停用成员之前,请验证有足够的其他拥有“批准”权限的成员保持活跃,以满足受影响工作流程所需的批准数量,或者如果您需要帮助,请联系支持团队。

疑难解答

系统要求至少有一名其他成员(除了您)在管理策略工作流程中拥有“批准”权限,然后才能锁定策略。如果没有独立的审批人,锁定将导致僵局,没有人可以批准未来的策略更改。请将管理策略上的“批准”权限分配给另一位成员,然后重试。

请检查该工作流程中拥有“批准”权限的成员是否仍有足够数量处于活跃状态。如果自请求创建以来,拥有“批准”权限的成员已被停用或移除,则剩余的审批人可能不足以达到所需的数量。待处理的请求将保留在创建时应用的审批阈值;现在更改策略不会降低已排队请求的要求。要解除阻止,请重新激活已停用的成员,或将“批准”权限分配给另一位活跃成员,以便满足原始阈值。如果访问管理也需要审批且相同的审批人不可用,请联系支持团队寻求帮助。

该工作流程的“始终要求审批”已开启。当此设置启用时,“执行”处于休眠状态 — 权限仍然已分配,但每个请求都必须经过独立审批。要为拥有“执行”权限的成员恢复立即完成功能,请将“始终要求审批”切换为关闭。请注意,这是一项管理策略操作 — 如果管理策略本身需要审批,则更改必须由独立成员批准后才能生效。请参阅上文“执行”与策略的交互。

此工作流程只有一名拥有“批准”权限的成员,并且该成员也拥有“发起”权限。由于成员无法批准自己的请求,因此他们的请求将没有符合条件的审批人。请将“批准”权限分配给至少一名其他成员,或者授予该成员“执行”权限,以便在策略允许时,他们可以无需审批即可完成操作。

停用不会因审批人短缺而受阻。如果您停用了在某些工作流中拥有批准权限的成员,请验证是否有足够的拥有批准权限的活跃成员来满足每个工作流所需的批准数量。如果某个工作流的审批人不足,请重新激活该成员,或将批准权限分配给受影响工作流中的其他活跃成员。这些工作流上的待处理请求将保留在队列中,直到达到所需的批准数量。

下一步是什么?

在您了解政策和审批的运作方式后,请参阅推行治理,获取一次一个工作流地引入审批要求的分步指南,其中包括选择性治理配置和完整治理配置的示例。

还需帮助?