Automation
构建和管理自动化
自动化规则应该是具体的、可测试的并且易于解释。强有力的规则使用明确的触发条件、狭窄的条件、安全的操作和受控的范围。
安全的自动化设置应该可以帮助您:
- 规划新的自动化规则。
- 在自动化构建器中构建规则。
- 查看并更改现有规则。
- 确认访问、计划和网络要求。
- 在依赖它之前测试行为。
构建器状态参考
| 状态 | 该怎么办 |
|---|---|
| 加载中 | 等待构建器初始化。 |
| 重试 | 选择重试。如果重复出现,请刷新应用程序并确认网络访问。 |
| 没有互联网 | 在打开或更改规则之前重新连接。 |
| 无法访问 | 请空间管理员审核您的角色。 |
| 升级提示 | 要求帐单所有者检查计划的可用性。 |
| 生成器已加载 | 从构建器创建、审查和管理规则。 |
规则设计参考
| 部分 | 定义 | 好的做法 |
|---|---|---|
| 名称 | 人们在构建器中看到的标签。 | 使用简单语言的目的,例如当任务移至审阅时分配审阅者。 |
| 触发 | 启动规则的事件。 | 选择最具体的可用事件。 |
| 条件 | 在操作运行之前必须满足的要求。 | 添加条件以防止意外匹配。 |
| 行动 | 执行的更新、通知、分配、提醒或其他操作。 | 保持第一个版本的低风险。 |
| 适用范围 | 应用规则的空间、列表或工作区域。 | 开始时缩小范围,然后仅在测试后进行扩展。 |
| 状态 | 规则是否可以运行。 | 在调查意外行为时暂停或禁用规则。 |
开始之前
- 您必须处于正确的空间。
- 您的角色必须允许自动化访问。
- 您的计划必须包括自动化访问。
- 在根据规则进行实际工作之前,请使用安全的测试项目。
在构建之前规划规则
按以下格式编写规则:
当[触发]发生时,如果[条件]为真,则[动作]。
示例:
- 当任务移至审阅时,指定审阅者。
- 当任务被标记为已阻止时,通知团队。
- 添加后续日期后,创建提醒。
创建自动化
- 打开自动化。
- 等待构建器加载。
- 开始新的规则。
- 清楚地命名规则。
- 选择触发器。
- 添加条件。
- 选择行动。
- 确认范围。
- 保存规则。
- 使用安全物品进行测试。
预期结果: 自动化已保存,仅影响匹配工作。
管理现有自动化
- 打开自动化。
- 选择您要查看的规则。
- 检查名称、触发器、条件、操作、范围和状态。
- 如果行为不确定,则暂停或禁用规则。
- 一次编辑一部分。
- 保存并重新测试。
安全设置清单
在依赖规则之前,请确认:
- 触发点是特定的。
- 条件阻止了广泛匹配。
- 动作是安全的。
- 范围仅限于预期区域。
- 一个测试项目产生了预期的结果。
- 受影响的团队了解自动更新。
- 您知道如何在需要时暂停或禁用规则。
故障排除
生成器一直显示重试
- 症状: 重试后构建器无法打开。
- 原因: 会话、网络、服务可用性或初始化详细信息可能丢失。
- 决议:
- 确认您在线。
- 刷新应用程序。
- 确认当前Space加载正确。
- 再试一次。
- 如果仍然失败,请报告大致的时间和空间。
规则影响太多工作
- 症状: 更改的项目数量超出预期。
- 原因: 触发器、条件或范围太宽泛。
- 决议:
- 暂停或禁用该规则(如果可用)。
- 范围狭窄。
- 添加更严格的条件。
- 使用一项匹配项和一项不匹配项进行测试。
人们对自动变化感到惊讶
- 症状: 团队成员不知道工作为何发生变化。
- 原因: 规则名称或团队流程可能无法解释自动化。
- 决议:
- 重命名该规则,使其目的更加明确。
- 告诉受影响的用户什么触发因素会导致该操作。
- 将高风险决策保持手动状态。
FAQ
新规则的范围应该有多大?
开始狭窄。仅在安全测试证明该行为后才进行扩展。
当规则导致意外更新时,我是否应该对其进行编辑?
如果构建器提供该选项,请先暂停或禁用它。然后编辑、测试并重新启用。