通知组
通知组用于维护组织内的通知接收渠道，供 RPC 和联动逻辑引用。当前页面提供邮件与企业微信 WebHook 两种通知方式。
配置方式
进入 告警管理 → 通知组 → 新增。旧文档中的“系统管理 → 通知组”不是当前菜单位置。
| 字段 | 必填与填写说明 |
|---|---|
| Id Name | 必填，通知组标识，与显示名称分开。 |
| 名称 | 必填，便于操作人员识别用途。 |
| 启用 | 新增默认关闭；只保存记录并不等于启用通知。 |
| 通知方式 | 必填，当前下拉选项为 email、WeCom WebHook，初值为 email。 |
| 标签 | 可选，可多选。 |
| 联系人 | 必填，可配置多个接收项，应与所选通知方式匹配。 |
| 备注 | 可选，记录用途和维护说明。 |
选择 WeCom WebHook 后仍需配置联系人。当前空白表单没有独立的“钉钉”“Slack”“Telegram”通知类型，不能把这些服务作为本页内置支持项。若使用自定义 RPC 对接其他通知服务，应单独说明相应脚本与服务配置。
通知配置与触发逻辑
通知组定义接收渠道；RPC 或联动逻辑负责决定何时通知、发送什么内容。
- 需要在平台保留告警并处理产生／恢复状态时，使用告警管理说明的 ALARM RPC 流程。
- 只需发送消息时，参考RPC 模型中的 notify 动作定义。
- 告警 RPC 的通知组参数、底层动作参数和联动模型返回值属于不同层次，按实际模型契约填写，不能只依据表单显示名称猜测参数键。
设备级通知配置可保存在服务端属性的 notify 数组中，供联动脚本读取。TriggerHelper 的使用及返回结构见联动模型。不要假定任意 RPC 的 params 会自动等同于设备服务端属性；回填行为应由该 RPC 的参数配置确定。
配置后核对
- 检查 Id Name 与名称是否混淆，通知方式是否正确。
- 检查联系人是否完整，以及通知组是否开启。
- 邮件方式还依赖系统平台 SMTP 配置。
- 检查设备是否挂载相应 RPC／联动模型，触发逻辑是否引用正确的通知组。
- 通知组保存成功只证明配置已保存；是否成功送达需结合执行日志和接收端结果判断。
不同渠道可能以不同方式显示标题、正文和换行；应按接收端支持的格式编写内容。需要验证送达时，使用明确的测试接收渠道，避免把保存或编辑操作误当作发消息测试。