可扩展的 Automation 系统设计

拥有 Template 编辑权限的内部用户负责创建 Automation。原来的配置使用 When … Then … Do …，Action 简单且固定时，整条规则像一句话一样容易读懂。

随着产品规划和部分客户需求带来新的 Integration，每增加一种能力，都需要补一套句子结构、投入设计支持，并在开发中增加特殊处理。句子仍然好读，但背后的系统已经不适合继续扩展。

改版范围较大，因此团队拆成两个 Task：先重构 Automation 配置，再加入 Data Reference，让后续 Action 可以复用 Workflow 前面已经产生的信息。

产品规划和客户需求提出了支持更多 Integration 的压力。我将两个 Task 带入 PM 和工程团队的内部评审，对齐配置规则、Account 的条件式出现、Integration Inputs、Data Reference 和错误状态。

这次对齐为改版建立了共同基线，但没有进行客户可用性测试，也没有衡量上线后的使用表现。

探索过程中，我先尝试保留句子式结构，把新配置继续放进 When / Then / Do。但加入不同 App 的字段和 Account 后，句子不断分支，仍然需要为每种能力单独设计，因此没有继续采用。

我把配置重新拆成三部分：App & Event → Account → Inputs。

App & Event 决定要执行什么；用户选定 Automation App 后，系统再判断是否显示 Account；Inputs 则承载执行所需的信息。

目标不是让所有配置完全相同，而是先定义稳定规则。此后开发可以按照规则增加新的 Automation 类型，不必每次都重新找设计处理。

新的 Automation 结构确定后，第二个 Task 开始处理 Workflow 数据。后续 Action 越来越依赖前面 Action 的输出，例如标题、日期、附件、表单提交文件和签署完成的文档。

Data Reference 让 Input 直接引用这些内容，不必让用户重新填写。文字 Input 只显示可用的文字数据；文件 Input 则匹配附件或生成的文档。

这样一来，Automation 不再是一组彼此独立的规则，而是 Workflow 中传递信息的一环。

Moxo 内置 Automation 可以使用已经定义好的 Input 字段。Integration Automation 的返回内容无法预先确定，因此 Inputs 使用另一种呈现方式。两者遵循同一套高层配置规则，但不会被强行做成相同样式。

外部 Account 和 Workflow 数据也带来更多失败情况。我完成了这部分的全流程交互设计，并按问题发生的时间整理状态：执行前、执行中，以及 Automation 最终未完成。

错误信息需要回答三件事：哪里出了问题、问题发生在哪一步、用户接下来要修复什么。

改版不再为每个 Action 单独拼接一句规则，而是先建立结构化配置。规则确定后，开发可以增加受支持的 Automation 类型，不必每次重新定义设计模式。

新的 Automation 结构先上线，之后加入 Data Reference、Text 与 File 引用、Integration Inputs、Moxo 内置 Event、第三方 Integration 和 Error handling。

目前没有 Adoption、完成率、错误率或任务时长数据，因此上线后的使用效果暂时不能证明。