本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# 工作區標頭中的通知
<a name="amazon-connect-notifications"></a>

## 了解應用程式內通知
<a name="understanding-notifications"></a>

應用程式內通知是出現在 Amazon Connect 標頭中的螢幕提醒。它們提供中央方式，將重要資訊傳達給登入 Amazon Connect 的使用者。通知可以傳送給管理員和客服人員。無論使用者位於哪個頁面，標頭圖示都會指出他們是否有未讀取的訊息。

![\[顯示三個未讀取通知的通知小工具。\]](http://docs.aws.amazon.com/zh_tw/connect/latest/adminguide/images/header-notifications.png)


**支援的使用案例**  
通知支援下列使用案例：
+ 系統通知，例如可用性影響、容錯移轉事件、政策變更和關鍵功能更新。
+ 您的團隊在 API 請求中為所需的使用案例指定的自訂組織訊息，例如訓練提醒、排程遵循提醒，以及向您的團隊發出的緊急通知。

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

通知會顯示在 Connect 標頭中，並帶有圖示 （指出未讀取訊息）。使用者按一下 圖示以檢視訊息。

![\[顯示使用者通知的通知小工具。\]](http://docs.aws.amazon.com/zh_tw/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 主控台中工作的使用者。

**測試和驗證接收**  
測試通知時，請遵循下列準則：
+ 在**廣泛部署之前進行測試**：先傳送至小型群組，以驗證內容和格式。
+ 請注意，通知會在建立後立即傳送；不支援排程交付。
+ **驗證交付**：將您自己包含在收件人清單中，以確認通知如預期顯示。