zoho crm当记录提交审批而锁定时用deluge更新字段的奇特逻辑

直接运行deluge是无法更新成功的，会报Not Approved，即使运行的身份是超级管理员。但是如果是触发workflow而执行deluge，这时就能更新成功了。

这是 Zoho CRM 中一个非常经典且鲜为人知的"底层逻辑差异"。

简单来说，直接运行 Deluge 脚本和通过工作流（Workflow）触发 Deluge 脚本，在 Zoho 的后台权限上下文中是不一样的。

以下是这个"奇特逻辑"的深度解析，以及为什么会出现这种情况：

1. 核心原因：上下文环境不同 (Context Matters)

• 场景 A：直接运行 Deluge（测试控制台、独立脚本、API 调用）

  • 权限判定： 当你直接在 Deluge 编辑器中点击"保存并执行"，或者通过外部 API 调用该函数时，系统将其视为一次常规的 API 数据更新请求。
  • 锁机制生效： 系统会严格检查记录的状态。如果记录处于"审批中（In Approval）"状态，记录是被**锁定（Locked）**的。
  • 结果： 此时，Zoho 的安全层逻辑是："记录已锁定，除了审批操作（批准/拒绝）外，禁止任何直接的数据修改"。因此，即使你是超级管理员，API 也会返回 RECORD_LOCKED 或 NOT_APPROVED 错误。

• 场景 B：通过工作流触发 Deluge（Workflow Automation）

  • 权限判定： 当工作流被触发时，该操作是在**系统后台（System Context）**级别执行的，或者是被视为自动化流程的一部分。
  • 特权通道： Zoho CRM 的设计逻辑认为，如果管理员预设了自动化规则（Workflow），说明这个数据变更是业务流程的一部分。系统级的自动化通常拥有"穿透"审批锁的特权。
  • 结果： 工作流携带的动作（包括触发的 Custom Function）会绕过标准的"记录锁定"检查，从而成功更新字段。

2. 及其类似的"双标"行为

这种逻辑不只存在于 Deluge 中，Zoho CRM 在其他地方也有类似的"双标"：

• 字段更新操作（Field Updates）： 你无法在 UI 界面上手动修改锁定记录的字段，但是如果此时发生了一个事件触发了一个配置了"字段更新"的工作流，那个字段是可以被自动修改的。
• 蓝图（Blueprint）： 当记录进入蓝图时也处于锁定状态。直接 API 更新通常会失败，但通过能够触发蓝图 Transition 的脚本或工作流有时可以修改数据。

3. 如何利用这个逻辑（解决方案）

既然你已经发现了这个机制，这实际上为你解决"如何在审批过程中修改数据"提供了一个官方后门（Workaround）。

如果你必须在审批期间通过代码更新字段，但直接运行脚本报错，你可以采用**"特洛伊木马"**策略：

1. 创建一个辅助字段： 例如一个复选框字段 Trigger_Update_Check（对普通用户隐藏）。
2. 创建一个工作流： 设定当 Trigger_Update_Check 被修改时触发。
3. 关联函数： 将你原本想运行的 Deluge 代码绑定在这个工作流上。
4. 执行操作： 你的主脚本或操作只需要更新这个 Trigger_Update_Check 字段（有时候仅仅更新非关键字段是被允许的，或者你可以寻找其他触发源），从而间接利用工作流的"超级权限"来完成对锁定字段的更新。

4. 总结

这确实是 Zoho 的一个特性（Feature）而非漏洞（Bug）。

• 直接 Deluge = 模拟用户/API 行为 -> 受制于锁。
• 工作流 Deluge = 模拟系统内部进程 -> 无视锁。