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