本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

# 工作区标题中的通知
<a name="amazon-connect-notifications"></a>

## 了解应用内通知
<a name="understanding-notifications"></a>

应用程序内通知是显示在 Amazon Connect 标题中的屏幕提醒。它们提供了一种向登录到 Amazon Connect 的用户传达重要信息的中心方式。可以向管理员和代理发送通知。无论用户在哪个页面上，标题图标都会显示他们是否有未读消息。

![通知控件显示三个未读通知。](http://docs.aws.amazon.com/zh_cn/connect/latest/adminguide/images/header-notifications.png)


**支持的用例**  
通知支持以下用例：
+ 系统通知，例如可用性影响、故障转移事件、策略更改和关键功能更新。
+ 您的团队在针对所需用例的 API 请求中指定的自定义组织消息，例如培训提醒、日程遵守情况提醒以及向团队发送的紧急通知。

## 通知的显示方式
<a name="how-notifications-appear"></a>

通知显示在 Connect 标题中，带有表示未读消息的图标。用户单击该图标可查看消息。

![显示用户通知的通知控件。](http://docs.aws.amazon.com/zh_cn/connect/latest/adminguide/images/notifications-widget.png)


通知面板显示：
+ **优先级指示器**：突出显示紧急消息
+ **消息内容**：每个本地化字符串最多 500 个字符，支持嵌入式链接
+ **标记为已读**：用户可以通过点击每封邮件右侧的操作菜单将其标记为已读或未读

未读通知以粗体显示，带有点状指示器，按最新到最旧顺序排列。阅读通知降低了视觉重点。没有时间对自己打开的消息做出回应的用户可以将其标记为未读，以此作为视觉提醒。

通知的默认可见性期限为一周。过期的消息会自动删除。

## 创建和管理通知（仅限 API）
<a name="create-notifications"></a>

任何用户无需额外权限即可*接收*通知，但需要特殊权限才能创建、编辑、删除和查看已发送的通知。

**重要**  
撰写和发送通知需要 API 权限。有关利用通知的更多信息， APIs 请参阅 [API 指南](https://docs.aws.amazon.com/connect/latest/APIReference/actions-by-resource.html)。

对有权管理通知的用户实施精细的访问控制：
+ **基于标签的访问控制 (TBAC)**：具有 TBAC 限制的管理员只能创建、编辑或删除与其分配的标签相匹配的通知。他们也只能向具有匹配标签的用户发送通知。
+ **基于层次结构的访问控制 (HBAC)**：管理员只能创建或管理发送给低于其层次结构级别的用户的通知。

您的团队可以执行以下通知操作：
+ 发送带有嵌入式链接的富文本消息
+ 翻译不同语言的消息以符合用户偏好（每个本地化字符串最多 500 个字符）
+ 指定每条消息的持续时间，即 “存活时间”，即 TTL（默认为 1 周）
+ 更新或删除现有消息
+ 一次向最多 200 个用户发送消息，或者在必要时向实例中的所有人发送消息
  + 
**重要**  
只有没有基于标签的访问控制 (TBAC) 限制或基于层次结构的访问控制 (HBAC) 限制的管理员才能为实例中的所有用户创建通知
+ 将紧急留言标记为高优先级，这样它们就更容易被看见

### 最佳实践
<a name="notification-best-practices"></a>

**重要**  
请勿包含个人身份信息 (PII)

**尽量减少通知过载**  
每个实例最多支持 500 个活动通知。通过以下方式避免通知疲劳的可能性：
+ **定位特定受众**：尽可能缩小范围。
+ **整合相关更新**：将信息分组为一条通知，而不是发送多条消息。
+ **避免多余消息**：在创建新通知之前，请考虑更新现有通知是否更合适。
+ **使用适当的优先级**：为真正重要的消息保留高优先级，以保持其有效性。
+ **提供简洁的消息**：在通知中包含指向完整文档的链接，而不是冗长的内容。

**管理正在发生的情况**  
对于生成多个更新的事件（例如天气中断或系统问题），请考虑：
+ 仅发送最相关的状态更改（例如，“事件已启动” 和 “事件已解决”）
+ 以合理的时间间隔调整更新节奏——避免用快速发送的消息让用户不知所措
+ 设定更新频率的预期（例如，“在条件改善之前，将每 10 分钟发送一次更新”）
+ 使用更新 API 修改现有通知，而不是为每次状态更改创建新通知

*示例*：如果恶劣天气影响了您的 IT 支持队列中的 320 个代理，请发送有关影响的初始警报。五分钟后，更新为当前状态：“仍有 170 个代理无法访问。” 按规定的间隔继续进行有意义的更新。

**何时使用替代品**  
在以下情况下，可以考虑通知的替代方案：
+ **对于跟踪的操作项目**：通知提供 CloudTrail 审计，但不如任务功能那么强大，后者提供分配、跟踪和报告功能。通知系统不提供送达确认或已读回执。
+ **对于需要保留数据的场景**：通知仅在其 TTL 到期或手动删除之前存储。默认 TTL 为一周。
+ **对于 AWS 控制台用户**：通知仅显示在 Connect 网站上。他们无法联系专门在 AWS 控制台中工作的用户。

**测试和验证收据**  
测试通知时，请遵循以下准则：
+ **在广泛部署之前进行测试**：先发送给一个小组，以验证内容和格式。
+ 请注意，通知会在创建后立即发送；不支持计划配送。
+ **验证送达**：将您自己包括在收件人列表中，以确认通知按预期显示。