All
筛选:
如何将法定货币存入我的账户?
我需要帮助进行账户验证
为什么无法访问我的账户?
是否有加密货币取款手续费?
我需要帮助登录我的账户
本指南将逐步介绍如何为每个工作流引入审批要求。系统采用渐进式部署设计:Organization初始运行灵活,所有者可独立完成一切操作;待准备就绪后,可逐一收紧各工作流规则,最终(如有需要)实现任何单人均无法独立转移资金或修改规则的管控架构。
如需了解策略的运作机制,请参阅策略、审批与治理。如需了解访问权限模型,请参阅角色、配置文件与权限。
Execute权限级别与“始终要求审批”设置组合形成两种管控模式:
不同工作流可采用不同的管控模式。常见配置方案:提款请求(Withdrawal Request)对全员启用审批;划转请求(Transfer Request)走快速通道(资金在Organization内部流转);管理策略(Manage Policies)启用审批,以保护规则本身。
前三个步骤均可随时撤销。锁定即为最终承诺。
第1步 初始化
所有者初始持有系统预设的Admin配置文件与Full access角色:对所有工作流拥有Execute权限,对所有账户拥有全部权限。每个工作流的策略初始均为开放状态。作为单用户组织,操作方式与以往完全一致,无需等待审批,因为并无他人可审批。
第2步 配置
在“始终要求审批”保持关闭的情况下,为某个工作流搭建审批设置(通常先从Withdrawal Request开始):
只有已接受邀请并完成验证的成员,才计入审批人数。已受邀成员在两项均完成前不计入审批人数,即使其已出现在团队列表中。
当前尚未执行任何规则。您仍保留Execute权限,可正常操作,同时完成各项配置。
第3步——验证
请为目标工作流开启“始终要求审批”。此后所有请求(包括您的)均进入队列等待审批。请通过实际请求进行验证:
此阶段为安全窗口期:治理规则已生效,但策略尚未锁定,您可随时关闭该设置、进行调整并重新测试。请在锁定策略前,确认最终状态是保持“始终要求审批”开启还是关闭。
第4步——锁定
请锁定策略。锁定本身属于一项Manage Policies请求:若Manage Policies已要求审批,则锁定须经另一位成员审批后方可生效。自此:
锁定后,任何个人均无法单独削弱此工作流的治理规则。后续变更(包括解锁)均须由可在Manage Policies中审批的独立审批人参与。成员变更角色或离职时,请确保审批人覆盖不中断。
第5步 - 重复
其他所有工作流均保持当前状态,直至您返回第2步对其进行配置。已治理与未治理工作流的任意组合均为有效的稳定状态。上述流程仅供参考,并非强制要求。
最后一步——锁定"管理策略"本身
"管理策略"拥有独立的策略与锁定设置。锁定后即标志着部署完成。此后,组织内任何工作流的任何规则变更(包括策略设置、锁定与解锁)均须经过独立审批,任何人都无法再单独通过产品放宽治理要求。
请在所有计划纳入治理的工作流均已完成配置并锁定后,再执行此步骤。请先确认:即使没有您的参与,"管理策略"请求仍可正常发起并获得审批——需有一名成员能够发起请求,另有足够数量的其他成员在"管理策略"上持有"审批"权限(数量与该工作流的要求一致),且所有相关成员均已完成验证并处于活跃状态。已锁定的策略仅在上述审批路径持续可用时方可修改,系统不会自动为您检查。有关此锁定功能的详细说明,请参阅策略、审批与治理。
某CFO希望自己能立即完成提款操作,同时要求资金经理的每笔提款均须经过其审批。
工作流配置文件:
成员 | 个人简介 | 提款请求权限级别 |
|---|---|---|
CFO | 自定义"CFO" | 查看、发起、审批、执行 |
资金经理A | 发起人(系统预设) | 查看、发起 |
资金经理B | 发起人(系统预设) | 查看、发起 |
三人均持有账户角色,对运营账户拥有提币权限。本示例中的权限级别仅针对提款请求。系统预定义的发起人配置文件同样授予对所有其他工作流的发起权限。若资金管理人只需发起提款请求、而不应发起其他受治理的操作,请使用自定义配置文件。
提款请求策略:所需审批数为1,“始终要求审批”已关闭,策略已锁定。
结果:CFO的提款通过执行权限即时完成。每位资金管理人的提款需等待一次审批,实际上由CFO审批,因为她是唯一的审批人。由于策略已锁定,任何人都无法单独更改这些规则。
锁定前,请确认在发起人缺席的情况下,管理策略请求仍可获得审批:持有管理策略审批权限的成员数量须满足该工作流的要求。这些成员负责审批未来的策略变更及解锁请求。系统不会为您自动检查此项。
后续收紧。若公司决定所有提款(包括CFO的提款)均需审查,则该变更须通过策略请求完成(由于策略已锁定,需经独立审批):
CFO的执行权限保留在其配置文件中,暂时处于休眠状态。若公司日后放宽策略,无需重新分配权限,她的快速通道即可自动恢复。
以下为提款请求工作流中四人团队的配置示例,展示每笔请求的审批资格如何确定:
成员 | 查看 | 发起 | 批准 | 执行 |
|---|---|---|---|---|
所有者 | 是 | 是 | 是 | 是 |
Alice | 是 | 是 | 是 | - |
Bob | 是 | - | 是 | - |
Charlie | 是 | 是 | - | - |
策略:所需审批数为2,“始终要求审批”已开启(因此所有者的执行权限处于休眠状态)。
场景 | 须由谁审批 | 原因 |
|---|---|---|
Owner发起 | Alice和Bob | Owner不能审批自己发起的请求;Alice和Bob是仅有的其他审批人,因此两人均须审批。 |
Alice发起 | Owner和Bob | Alice不参与自己发起的请求审批;其余审批人为Owner和Bob。 |
Charlie发起 | Owner、Alice、Bob中任意2人 | Charlie不持有审批权限,因此三位审批人均可审批其请求。 |
Bob发起 | - | Bob不持有发起权限,无法创建提款请求。他仅承担审批职责,这是许多团队刻意设置的纯审批人角色。 |