Introduction

Cet article fournit des informations sur la transition vers le nouveau service de notification, notamment :

• Des réponses aux questions fréquemment posées
• Les différences notables par rapport à l’ancien service de notification
• Des cConsidérations relatives à la migration des notifications préexistantes

Pour la documentation principale du nouveau service de notification, consultez les articles de la base de connaissances : 

Configurer des notifications
Codes courts dans les notifications
Événements et conditions des notifications

Pour en savoir plus sur le calendrier de déploiement, consultez le billet : Déploiement du nouveau service de notification : plan de publication progressive | Community. 

Migration des notifications existantes

Avec la migration vers le nouveau moteur de notification, les notifications existantes seront transférées automatiquement, de sorte que dans la plupart des cas, vous n’aurez pas besoin d’effectuer la moindre opération manuelle. Cependant, consultez le reste de cet article pour découvrir quelques points que vous pourriez vouloir vérifier.

Syntaxe des codes courts

Auparavant, les codes courts insérés dans le corps d’un message étaient délimités par des crochets, par exemple [course_link]. 

Dans les nouvelles notifications, tous les codes courts sont désormais délimités par des doubles accolades, par exemple : {{course_link}}.

Une fois la migration de votre plateforme vers le nouveau service de notification effectuée, les codes courts de vos notifications existantes seront automatiquement convertis à la nouvelle syntaxe. Vous n’avez donc rien à ajuster manuellement.

URL de base pour les liens dans les notifications

Avec la transition vers le nouveau service de notification, le système insère automatiquement dans les liens des notifications l’URL de base correcte pour chaque destinataire. Cela signifie que :

• Chaque personne recevant un message contenant un code court tel que {{course_link}} obtiendra un lien ciblant son client d’entreprise étendue spécifique.
• Il n’est pas nécessaire de configurer des versions séparées d’une notification pour chaque client de l’entreprise étendue.
• L’URL de base d’une notification n’est plus affectée par son type de planification, ni par l’individu modifiant ou enregistrant la notification.

Pour en savoir plus, consultez l’article Codes courts dans les notifications >  Codes courts de liens et domaines d’entreprise étendue. 

Code court de pièce jointe calendrier

Avec le nouveau service de notification, l’ancien code court [calendar_attachment] n’est plus utilisé. À la place, vous pouvez maintenant ajouter des pièces jointes de calendrier via un sélecteur dans l’interface utilisateur.

Lors de la migration des notifications existantes contenant l’ancien code court vers le nouveau service, le système supprimera automatiquement [calendar_attachment] du corps du message et ajoutera la nouvelle pièce jointe de calendrier.

Par conséquent, vous devrez peut-être revoir et ajuster manuellement le corps des messages des notifications qui utilisaient auparavant ce code court. Par exemple, une phrase telle que « Lien calendrier pour la session : [calendar_attachment] » sera raccourcie à « Lien de calendrier pour la session : »   

Dans ce cas, vous devriez réviser la phrase pour que le message affiche quelque chose comme « Le lien du calendrier pour la session est joint à ce message. »

Notification « L’apprenant a terminé un plan de formation »

Pour ceux utilisant la notification L’apprenant a terminé un plan de formation déclenchée par les utilisateurs appartenant à une branche, et destinée à des Power Users et Superadmins, avec la migration vers le nouveau moteur de notification, ces destinataires recevront désormais des notifications uniquement pour les utilisateurs appartenant à la branche déclencheuse. Ils ne recevront plus de notifications pour tout utilisateur de la plateforme ayant terminé le plan de formation.

Migration des plannings de notification

Dans le nouveau service de notification, les plages temporelles prises en charge par le Planificateur doivent correspondre aux intervalles ci-dessous : 

Heures :  1→72 
Jours :   1→365
Semaines :  1→52 
Mois : 1→24 

Les notifications programmées héritées dont les plages temporelles ne correspondent pas aux intervalles ci-dessus seront migrées en appliquant la règle de conversion suivante :

Convertir la valeur à l’unité de mesure supérieure jusqu’à atteindre une valeur permise. Par exemple :

73 heures → 4 jours
371 jours → 53 semaines → 13 mois

L’heure est toujours réglée sur 00:00 (correspondant à minuit) selon le fuseau horaire défini.

Aucune notification dont la plage temporelle dépasse 24 mois (par exemple 200 semaines) ne sera migrée. 

En conséquence, après la migration de vos notifications préexistantes, il vous faudra peut-être ajuster la plage temporelle obtenue à la suite de la conversion et définir une heure différente pour l’envoi de la notification.

Codes courts incorrects dans des modèles migrés

Uniquement pour les plateformes sandbox qui ont été migrées pour la première fois vers le nouveau service de notification en décembre 2024 - En raison d’un problème avec certains modèles de message, les types de notification suivants doivent être vérifiés et corrigés manuellement :

Utilisateur créé (par l'administrateur)
Utilisateur créé (inscription confirmée)
Nouvelle version de la politique de confidentialité
Nouvelle question un expert

Plus précisément, les notifications préexistantes basées sur les modèles affectés peuvent contenir des codes courts incorrects tels que :

{{firstname}} → le code correct est {{first_name}}
{{lastname}} → le code correct est {{last_name}}
{{password}} → le code correct est {{user_password}}

Ils peuvent également contenir des codes courts qui ne figurent même pas parmi ceux autorisés pour cette notification.  Par exemple : {{firstname}} alors que seul le code {{username}} peut figurer dans l’événement de la notification.

À noter : ce problème n’affecte pas les plateformes ayant pour la première fois fait l’objet d’une   migration vers le nouveau service de notification en janvier 2025 ou après cette date. Il affecte uniquement les sandboxes initialement migrées en décembre 2024, puis restaurées.

Que faire :

Si votre plateforme fait partie de celles potentiellement affectées, vous devez :

• Vérifier toutes les notifications préexistantes des types d’événements affectés, et corriger manuellement tout code court erroné. Les codes courts autorisés et leur syntaxe correcte sont indiqués dans la section Shortcodes de l’espace de rédaction du message.

Astuce : le problème affecte uniquement les notifications préexistantes des types d’événements affectés, et qui ont été migrées depuis l’ancien système. Les modèles ont ensuite été corrigés, donc lorsque vous créez de nouvelles notifications de ces types, les codes courts seront corrects.

Migration des notifications ciblant des cours supprimés

Après la transition vers le nouveau moteur de notification, vous pourrez constater que certaines de vos notifications préexistantes ciblent désormais un public plus large qu’auparavant, et sont envoyées de manière inattendue à un grand nombre d’utilisateurs. 

Si cela se produit, la cause peut être une notification migrée ciblant des cours supprimés ou inactifs. Ces notifications n’ont en effet aucun filtre de contenu appliqué (car tout le contenu ciblé a été supprimé ou désactivé).

• Avec l’ancien système, les notifications sans filtres de contenu n’étaient pas envoyées.
• Avec le nouveau service de notification, une notification sans filtres de contenu (si elle a été enregistrée par un Superadmin) sera déclenchée pour tous les cours et plans de formation de la plateforme. 

Recommandation : passez en revue toutes les notifications migrées qui auraient auparavant pu cibler des cours supprimés ou inactifs. Ces notifications peuvent maintenant être interprétées comme globales (non filtrées) et pourraient être diffusées plus largement que prévu.

Pour plus d’informations, consultez le post sur ce sujet sur le portail communautaire (s’ouvre dans un nouvel onglet). 

Migration des notifications dans l’entreprise étendue

Si vous avez migré des notifications d’une entreprise étendue, selon leur configuration, vous pouvez être affecté par le changement suivant concernant les destinataires et la portée des déclencheurs : 

Avec l’ancien service de notification, les déclencheurs et destinataires d’une notification étaient automatiquement restreints aux utilisateurs du client de l’entreprise étendue où cette notification était configurée et enregistrée. Cela se produisait même si aucun filtre de branche n’était défini.
Ainsi, vous pouviez configurer :

• Plusieurs versions de la même notification, chacune ciblant les utilisateurs d’un client différent de l’entreprise étendue.
• Cela pouvait être réalisé sans filtre de branche, simplement en enregistrant chaque notification dans le client approprié de l’entreprise étendue. 

Avec le nouveau service de notification, les déclencheurs et destinataires d’une notification ne sont plus restreints au client de l’entreprise étendue sur lequel la notification est enregistrée. Donc, si vous avez migré des notifications configurées comme décrit ci-dessus, certains utilisateurs peuvent désormais recevoir des notifications en double. 

Vous pouvez corriger cela de deux manières :

• Méthode 1 : ajouter des filtres de branche - Conservez les différentes versions de la même notification, mais insérez dans chacune le filtre de branche approprié, correspondant au client qu’elle doit cibler dans l’entreprise étendue.
• Méthode 2 : utiliser une notification unique - Remplacez les différentes versions de la même notification par une notification unique qui fonctionnera pour les destinataires appartenant à tous les clients de l’entreprise étendue. Rappelez-vous que tous les liens de codes courts utiliseront automatiquement l’URL de base correcte pour chaque destinataire. Vous pouvez également utiliser le shortcode {{extend_enterprise_logo}} pour insérer dynamiquement le logo correct de la plateforme.  

 Exemple : avec l’ancien service de notification, vous aviez configuré : 

• Utilisateur inscrit à un cours sans filtres de branche, enregistré sur le domaine A : la notification est déclenchée uniquement par les utilisateurs appartenant au domaine A, et envoyée uniquement aux destinataires appartenant au domaine A
• Utilisateur inscrit à un cours sans filtres de branche, enregistré sur le domaine B : la notification est déclenchée uniquement par les utilisateurs appartenant au domaine B, et envoyée uniquement aux destinataires appartenant au domaine B.  

Après la migration vers le nouveau service de notification, ces deux notifications peuvent être déclenchées par un utilisateur appartenant à n’importe quel domaine, et seront envoyées aux destinataires appartenant à n’importe quel domaine. Ainsi, un utilisateur s’inscrivant à un cours déclenchera et recevra les notifications des domaines A et B.

Migration de la notification « Utilisateur inscrit à un groupe »

Avec l’ancien système, la notification « Utilisateur inscrit à un groupe » n’appliquait pas les filtres de déclenchement des branches.

En conséquence, lorsque des déclencheurs de groupe et de branche étaient spécifiés, la notification se déclenchait toujours chaque fois qu’un utilisateur était ajouté à l’un des groupes spécifiés, quelle que soit sa branche.

Avec le nouveau service de notification, les filtres de déclenchement de branche sont désormais également appliqués, en utilisant la logique AND. Cela signifie que la notification ne se déclenchera que lorsqu’un utilisateur appartenant à l’une des branches spécifiées est également ajouté à l’un des groupes indiqués. 

Pour en savoir plus sur la logique de cette notification, consultez l’article Événements et conditions des notifications > Notification « Utilisateur inscrit à un groupe ».