View a markdown version of this page

Notifications dans l'en-tête de l'espace de travail - Amazon Connect

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Notifications dans l'en-tête de l'espace de travail

Comprendre les notifications intégrées à l'application

Les notifications intégrées à l'application sont des alertes à l'écran qui apparaissent dans l'en-tête Amazon Connect. Ils constituent un moyen centralisé de communiquer des informations importantes aux utilisateurs connectés à Amazon Connect. Les notifications peuvent être envoyées aux administrateurs et aux agents. Quelle que soit la page sur laquelle se trouve un utilisateur, l'icône d'en-tête indique s'il a des messages non lus.

Le widget de notifications affiche trois notifications non lues.
Cas d'utilisation pris en charge

Les notifications prennent en charge les cas d'utilisation suivants :

  • Notifications système telles que les impacts sur la disponibilité, les événements de basculement, les modifications de politique et les mises à jour de fonctionnalités critiques.

  • Messages organisationnels personnalisés spécifiés dans les demandes d'API de votre équipe pour les cas d'utilisation souhaités, par exemple des rappels de formation, des alertes de conformité au calendrier et des notifications d'urgence destinées à vos équipes.

Comment apparaissent les notifications

Les notifications s'affichent dans l'en-tête Connect avec une icône indiquant un ou plusieurs messages non lus. Les utilisateurs cliquent sur l'icône pour afficher les messages.

Le widget de notifications qui affiche les notifications d'un utilisateur.

Le panneau de notification affiche :

  • Indicateur de priorité : les messages urgents sont soulignés

  • Contenu du message : jusqu'à 500 caractères par chaîne localisée, avec prise en charge des liens intégrés

  • Marquer comme lu : les utilisateurs peuvent marquer comme lu ou non lu en cliquant sur le menu d'actions à droite de chaque message

Les notifications non lues apparaissent en gras avec un indicateur à points, séquencées de la plus récente à la plus ancienne. Les notifications de lecture ont réduit l'accent visuel. Les utilisateurs qui n'ont pas le temps de réagir à un message ouvert peuvent le marquer comme non lu en guise de rappel visuel.

Les notifications ont une période de visibilité par défaut d'une semaine. Les messages expirés sont automatiquement supprimés.

Création et gestion de notifications (API uniquement)

Tout utilisateur peut recevoir des notifications sans autorisation supplémentaire, mais une autorisation spéciale est requise pour créer, modifier, supprimer et consulter les notifications envoyées.

Important

La rédaction et l'envoi d'une notification nécessitent des autorisations d'API. Pour plus d'informations sur l'utilisation des notifications, APIs consultez le guide de l'API.

Des contrôles d'accès granulaires sont appliqués aux utilisateurs autorisés à gérer les notifications :

  • Contrôle d'accès basé sur les balises (TBAC) : les administrateurs soumis à des restrictions TBAC peuvent uniquement créer, modifier ou supprimer des notifications correspondant aux balises qui leur ont été attribuées. Ils peuvent également envoyer des notifications uniquement aux utilisateurs dont les balises correspondent.

  • Contrôle d'accès basé sur la hiérarchie (HBAC) : les administrateurs peuvent uniquement créer ou gérer les notifications envoyées aux utilisateurs inférieurs à leur niveau hiérarchique.

Votre équipe peut effectuer les actions de notification suivantes :

  • Envoyez des messages texte enrichis avec des liens intégrés

  • Translate le message dans différentes langues pour l'aligner sur les préférences de l'utilisateur (jusqu'à 500 caractères par chaîne localisée)

  • Spécifiez la durée de chaque message, sa « durée de vie », c'est-à-dire le TTL (la valeur par défaut est de 1 semaine)

  • Mettre à jour ou supprimer des messages existants

  • Envoyer à un maximum de 200 utilisateurs à la fois ou, si nécessaire, à tous les membres de l'instance

    • Important

      Seuls les administrateurs ne disposant pas de restrictions de contrôle d'accès basé sur les balises (TBAC) ou de restrictions de contrôle d'accès basé sur la hiérarchie (HBAC) peuvent créer des notifications pour tous les utilisateurs d'une instance

  • Marquez les messages urgents comme prioritaires afin qu'ils soient plus visibles

Bonnes pratiques

Important

N'incluez pas d'informations personnelles identifiables (PII)

Minimiser la surcharge de notifications

Jusqu'à 500 notifications actives par instance sont prises en charge. Évitez le risque de fatigue liée aux notifications en :

  • Cibler des publics spécifiques : utilisez le filet le plus étroit possible.

  • Consolidation des mises à jour associées : regroupez les informations dans une seule notification plutôt que d'envoyer plusieurs messages.

  • Éviter les messages redondants : avant de créer une nouvelle notification, demandez-vous s'il serait plus approprié de mettre à jour une notification existante.

  • Utiliser une priorité appropriée : accordez une priorité élevée aux messages vraiment importants afin de maintenir leur efficacité.

  • Fournir des messages succincts : incluez des liens vers la documentation complète plutôt que de longs contenus dans les notifications.

Gérez les situations en cours

Pour les événements qui génèrent plusieurs mises à jour (tels que les perturbations météorologiques ou les problèmes du système), pensez à :

  • Envoyer uniquement les modifications de statut les plus pertinentes (par exemple, « incident déclenché » et « incident résolu »)

  • Rythme des mises à jour à intervalles raisonnables : évitez de surcharger les utilisateurs avec des messages rapides

  • Définir les attentes concernant la fréquence des mises à jour (par exemple, « Des mises à jour seront envoyées toutes les 10 minutes jusqu'à ce que les conditions s'améliorent »)

  • Utiliser l'API de mise à jour pour modifier les notifications existantes plutôt que d'en créer de nouvelles pour chaque changement de statut

Exemple : si des conditions météorologiques extrêmes affectent 320 agents de votre file d'assistance informatique, envoyez une alerte initiale indiquant l'impact. Cinq minutes plus tard, mise à jour avec l'état actuel : « 170 agents n'ont toujours pas accès ». Continuez à effectuer des mises à jour pertinentes à des intervalles définis.

Quand utiliser des alternatives

Envisagez des alternatives aux notifications dans les scénarios suivants :

  • Pour les actions suivies : les notifications fournissent un CloudTrail audit mais ne sont pas aussi robustes que la fonctionnalité Tâches, qui fournit des fonctionnalités d'attribution, de suivi et de reporting. Le système de notification ne fournit pas de confirmation de livraison ni ne lit les reçus.

  • Pour les scénarios nécessitant la conservation des données : les notifications ne sont stockées que jusqu'à l'expiration de leur TTL ou jusqu'à ce qu'elles soient supprimées manuellement. Le TTL par défaut est d'une semaine.

  • Pour les utilisateurs de la console AWS : les notifications apparaissent uniquement sur le site Web Connect. Ils ne peuvent pas atteindre les utilisateurs travaillant exclusivement dans la console AWS.

Tester et vérifier le reçu

Suivez ces directives lorsque vous testez les notifications :

  • Test avant un déploiement à grande échelle : envoyez d'abord à un petit groupe pour valider le contenu et le formatage.

  • Sachez que les notifications sont envoyées immédiatement après leur création ; la livraison planifiée n'est pas prise en charge.

  • Vérifier la livraison : inscrivez-vous dans la liste des destinataires pour confirmer que la notification apparaît comme prévu.