翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
ワークスペースヘッダーの通知
アプリ内通知について
アプリ内通知は、Amazon Connect ヘッダーに表示される画面上のアラートです。これらは、Amazon Connect にログインしているユーザーに重要な情報を伝えるための一元的な方法を提供します。通知は管理者とエージェントに送信できます。ユーザーがどのページにいるかにかかわらず、未読メッセージがあるかどうかがヘッダーアイコンに表示されます。
サポートされているユースケース
通知は、次のユースケースをサポートしています。
可用性への影響、フェイルオーバーイベント、ポリシーの変更、重要な機能の更新などのシステム通知。
トレーニングのリマインダー、スケジュール遵守アラート、チームへの緊急通知など、必要なユースケースのためにチームによって API リクエストで指定されたカスタム組織メッセージ。
通知の表示方法
Connect ヘッダーに通知が表示され、未読メッセージ (複数可) を示すアイコンが表示されます。ユーザーはアイコンをクリックしてメッセージを表示します。
通知パネルには以下が表示されます。
優先度インジケータ: 緊急メッセージを強調する
メッセージコンテンツ: ローカライズされた文字列あたり最大 500 文字、埋め込みリンクをサポート
既読としてマーク: 各メッセージの右側にあるアクションメニューをクリックすると、既読または未読としてマークできます。
未読の通知は、ドットインジケータとともに太字で表示され、最新から最も古い順に並べられます。読み取り通知により、視覚的な強調が軽減されます。開いたメッセージに応答する時間がないユーザーは、視覚的なリマインダーとして未読としてマークできます。
通知のデフォルトの可視性期間は 1 週間です。期限切れのメッセージは自動的に削除されます。
通知の作成と管理 (API のみ)
すべてのユーザーは追加のアクセス許可なしで通知を受け取ることができますが、送信された通知を作成、編集、削除、表示するには特別なアクセス許可が必要です。
重要
通知を作成して送信するには、API アクセス許可が必要です。通知 APIs の活用の詳細については、 API ガイドを参照してください。
通知を管理する権限を持つユーザーには、きめ細かなアクセスコントロールが適用されます。
タグベースのアクセスコントロール (TBAC): TBAC 制限を持つ管理者は、割り当てられたタグに一致する通知のみを作成、編集、または削除できます。また、一致するタグを持つユーザーにのみ通知を送信することもできます。
階層ベースのアクセスコントロール (HBAC): 管理者は、階層レベルより下のユーザーに送信された通知のみを作成または管理できます。
チームは次の通知アクションを実行できます。
リンクが埋め込まれたリッチテキストメッセージを送信する
ユーザー設定に合わせてメッセージを異なる言語で翻訳する (ローカライズされた文字列あたり最大 500 文字)
各メッセージの期間、「有効期限」、つまり TTL を指定します (デフォルトは 1 週間）。
既存のメッセージの更新または削除
一度に最大 200 ユーザーに送信するか、必要に応じてインスタンス内の全員に送信する
重要
タグベースのアクセスコントロール (TBAC) の制限または階層ベースのアクセスコントロール (HBAC) の制限がない管理者のみが、インスタンス内のすべてのユーザーに通知を作成できます。
緊急メッセージを高い優先度でフラグ付けして表示しやすくする
ベストプラクティス
重要
個人を特定できる情報 (PII) を含めない
通知の過負荷を最小限に抑える
インスタンスあたり最大 500 件のアクティブな通知がサポートされています。通知の疲労の可能性を回避するには、以下を実行します。
特定の対象者をターゲットにする: できるだけ狭いネットをキャストします。
関連する更新の統合: 複数のメッセージを送信するのではなく、情報を 1 つの通知にグループ化します。
冗長なメッセージの回避: 新しい通知を作成する前に、既存の通知を更新する方が適切かどうかを検討してください。
適切な優先度の使用: 真に重要なメッセージの有効性を維持するために、優先度の高いメッセージを予約します。
簡潔なメッセージの提供: 通知に長いコンテンツではなく、完全なドキュメントへのリンクを含めます。
進行中の状況を管理する
複数の更新を生成するイベント (天候の中断やシステムの問題など) については、次の点を考慮してください。
最も関連性の高いステータス変更のみを送信する (例：「インシデント開始」および「インシデント解決済み」)
妥当な間隔でのペース調整の更新 — 急激なメッセージでユーザーを圧倒しないようにする
更新頻度に関する期待の設定 (例：「条件が改善するまで 10 分ごとに更新が送信されます」)
ステータス変更ごとに新しい通知を作成するのではなく、更新 API を使用して既存の通知を変更する
例: 厳しい天候が IT サポートキュー内の 320 人のエージェントに影響する場合は、その影響について初期アラートを送信します。5 分後、現在のステータスで更新します。「170 人のエージェントがアクセスできません」。定義された間隔で意味のある更新を続行します。
重要
通知は、ユーザーがページを移動したりブラウザを更新したりするたびに更新されます。
代替手段を使用するタイミング
これらのシナリオでは、通知の代替方法を検討してください。
追跡されたアクション項目の場合: 通知は CloudTrail 監査を提供しますが、割り当て、追跡、レポート機能を提供するタスク機能ほど堅牢ではありません。通知システムは、配信確認や読み取り受信を提供しません。
データ保持が必要なシナリオの場合: 通知は TTL の有効期限が切れるか、手動で削除されるまでのみ保存されます。デフォルトの TTL は 1 週間です。
AWS コンソールユーザーの場合: 通知は Connect ウェブサイトにのみ表示されます。AWS コンソールでのみ作業するユーザーにはアクセスできません。
受信のテストと検証
通知をテストするときは、次のガイドラインに従ってください。
広範なデプロイ前にテストする: まず小さなグループに送信して、コンテンツとフォーマットを検証します。
通知は作成直後に送信されます。スケジュールされた配信はサポートされていません。
配信の確認: 受信者リストに自分を含めて、通知が期待どおりに表示されることを確認します。
