Modèles de notification

Les modèles de notification sont des conceptions de messages réutilisables pour les emails, les notifications push, les SMS, les messages in-app, le web et d'autres flux. Ils gardent les messages système cohérents, plus faciles à maintenir et prêts pour une diffusion multilingue.

• Liste des modèles de notification : https://admin.acusolo.net/admin/notification-templates
• Liste des modèles de notification localisés : https://admin.acusolo.net/admin/app-settings/localized-notification-templates

Liste des modèles

La liste des modèles de notification affiche tous les modèles de base.

Les admins peuvent :

• Voir tous les modèles de base.
• Rechercher des modèles.
• Créer un nouveau modèle.
• Modifier un modèle existant.
• Supprimer un modèle.
• Activer ou désactiver un modèle.
• Marquer un modèle comme modèle système.
• Vérifier le type, la catégorie et la priorité.

Colonnes du tableau

Colonne	Rôle
No.	Numéro de ligne.
Actions	Modifier ou supprimer le modèle.
Status	Indique si le modèle est actif ou inactif.
Name	Nom interne visible par les admins et description optionnelle.
Type	Type de livraison, comme push, in-app, email ou SMS.
Category	Catégorie métier, comme général, paiement, support, alerte sécurité, promotionnel, conseil santé ou motivationnel.
Priority	Niveau de priorité, comme faible, normal, élevé ou urgent.
System Template	Indique si le modèle est un modèle système ou personnalisé.
Timestamp	Date de création et de dernière mise à jour.

Créer un modèle de notification

Cliquez sur New Notification Template pour ouvrir le modal de création.

Champs de création

Champ	Rôle
Template Name	Obligatoire. Nom admin utilisé pour identifier le modèle.
Notification Type	Obligatoire. Définit le canal de livraison, comme push, in-app, email ou SMS.
Template Plain Text Body	Description admin optionnelle ou résumé texte du modèle.
Additional Data	Valeurs structurées optionnelles pour un comportement avancé. La plupart des admins ne doivent modifier ce champ que s'ils connaissent le format attendu.
Notification Subject / Title	Obligatoire. Titre ou sujet affiché à l'utilisateur.
Notification Body	Obligatoire. Contenu principal du message. Une mise en forme visuelle peut être utilisée pour les modèles email.
Variables	Liste optionnelle de valeurs dynamiques utilisées dans le titre ou le contenu.
Category	Obligatoire. Regroupe le modèle par objectif métier.
Priority	Obligatoire. Définit le niveau d'importance du message.
Active	Permet au modèle d'être utilisé.
System Template	Marque le modèle comme modèle système.

Exemple de modèle email visuel

Certains modèles peuvent contenir un contenu email complet et visuel.

Les modèles visuels sont utiles pour les messages de paiement, les commandes, les emails de sécurité de compte et d'autres communications système formelles. Le contenu du modèle doit préserver la mise en page, la marque, les liens et les variables prévues.

Variables de modèle

Les modèles peuvent inclure des variables dans le titre ou le contenu.

Exemples :

Quand une notification est envoyée, ces variables sont remplacées par de vraies valeurs. Les admins ne doivent pas supprimer les variables obligatoires sauf si le flux concerné n'en a plus besoin.

Modifier un modèle de notification

Cliquez sur l'action de modification dans une ligne pour ouvrir le modal d'édition.

Le modal d'édition est prérempli avec les données existantes du modèle sélectionné.

Les admins peuvent modifier :

• Nom du modèle.
• Type de notification.
• Description ou corps texte.
• Données supplémentaires.
• Sujet ou titre.
• Contenu du message.
• Variables.
• Catégorie.
• Priorité.
• Statut actif.
• Marqueur de modèle système.

Les changements affectent les futures notifications qui utilisent ce modèle. Les notifications déjà envoyées ne sont pas modifiées rétroactivement.

Suppression et statut

Les modèles utilisent le modèle standard de confirmation de suppression. Après confirmation, le modèle est retiré de la liste.

Avant de supprimer un modèle, les admins doivent vérifier s'il est lié à des versions localisées ou utilisé par des flux automatiques.

Comportement du statut :

• Actif : le modèle peut être utilisé pour les notifications.
• Inactif : le modèle reste dans le système mais ne doit pas être utilisé pour de nouvelles notifications.

Modèles de notification localisés

Les modèles localisés connectent un modèle de base à une langue et à un objectif précis.

Cela permet à Acusolo d'utiliser le même objectif de notification tout en servant différentes versions de langue aux utilisateurs.

Les admins peuvent :

• Voir les modèles localisés.
• Créer un modèle localisé.
• Modifier un modèle localisé.
• Supprimer un modèle localisé.
• Activer ou désactiver un modèle localisé.
• Définir une version localisée comme version par défaut pour un modèle, un type et une cible donnés.

Colonnes du tableau localisé

Colonne	Rôle
No.	Numéro de ligne.
Actions	Modifier ou supprimer le modèle localisé.
Status	Indique si cette version localisée est active.
Default	Marque la version localisée par défaut pour l'objectif correspondant.
Title	Titre admin de la version localisée.
Template	Modèle de base connecté à cet enregistrement localisé.
Language	Langue assignée à cette version.
Type	Type de livraison, comme Email, SMS, Push, In App, Web ou Other.
Target	Événement ou objectif utilisé par ce modèle localisé.
Timestamp	Date de création et de dernière mise à jour.

Créer un modèle localisé

Cliquez sur New Localized Notification Template pour ouvrir le modal de création.

Champs du modèle localisé

Champ	Rôle
Title	Obligatoire. Titre admin pour cette version localisée.
Notification Template	Obligatoire. Sélectionne le modèle de base auquel cette version appartient.
Language	Obligatoire. Sélectionne la langue de cette version.
Template Type	Obligatoire. Sélectionne le canal de livraison. Options : Email, SMS, Push, In App, Web et Other.
Template Target	Obligatoire. Sélectionne l'événement ou l'objectif du modèle.

Les cibles courantes incluent :

• Messages d'inscription et de connexion.
• Messages de mot de passe oublié et de réinitialisation.
• Vérification email, téléphone et OTP.
• Alertes de connexion depuis un nouvel appareil.
• Succès, échec, annulation, remboursement et rappel de paiement d'abonnement.
• Succès ou échec d'achat d'appareil.
• Succès ou échec d'achat d'accessoire.
• Statuts de commande et de livraison.

Modifier un modèle localisé

Cliquez sur l'action de modification dans une ligne localisée pour ouvrir le modal d'édition.

Le modal d'édition est prérempli avec les données existantes du modèle localisé sélectionné.

Les admins peuvent modifier :

• Titre.
• Modèle de base.
• Langue.
• Type de modèle.
• Cible du modèle.

Changer la langue ou la cible modifie quand et où cette version localisée est utilisée. Les admins doivent vérifier que le modèle de base sélectionné correspond bien à la cible prévue.

Comportement de la version par défaut

Le switch Default identifie la version localisée de secours pour un même modèle de base, type de livraison et objectif.

Si une version localisée est définie comme par défaut, les autres versions localisées du même groupe ne sont plus par défaut. Cela évite les conflits entre plusieurs versions par défaut.

Un modèle localisé par défaut doit rester actif. Si un modèle par défaut doit être désactivé, une autre version active doit d'abord être choisie comme version par défaut.

Modèles préparés

Certains modèles de notification sont préparés à l'avance afin que le système dispose de messages transactionnels prêts à l'emploi.

Exemples préparés :

• Paiement réussi.
• Rappel de paiement.
• Succès ou annulation de commande.
• Vérification OTP.
• Connexion depuis un nouvel appareil.
• Mot de passe modifié.
• Succès ou annulation d'achat d'appareil.
• Succès ou annulation d'achat d'accessoire.

Ces modèles préparés aident le système à démarrer avec du contenu complet sans demander aux admins de créer manuellement chaque message transactionnel.

Règles importantes

• Le nom du modèle est obligatoire.
• Le titre ou sujet du modèle est obligatoire.
• Le contenu du modèle est obligatoire.
• Les modèles localisés nécessitent un modèle de base et une langue.
• Les variables doivent rester cohérentes avec le flux concerné.
• Les mises en page email visuelles doivent être testées avant utilisation.
• Les modèles inactifs ne doivent pas être utilisés pour de nouvelles notifications.
• Ne supprimez pas un modèle de base si des versions localisées ou des flux automatiques en dépendent.
• Une seule version localisée doit être par défaut pour une même combinaison de modèle, type et cible.

Cas d'erreur fréquents

Les admins peuvent rencontrer ces cas :

• Des champs obligatoires sont manquants.
• Les variables sont écrites incorrectement.
• Les données supplémentaires ont un format invalide.
• Un modèle localisé est créé sans langue.
• Un modèle localisé est lié au mauvais modèle de base.
• Plusieurs versions localisées existent pour le même objectif sans version par défaut claire.
• Un modèle est inactif, donc le flux de notification ne peut pas l'utiliser.
• Un modèle email visuel perd sa mise en page parce que la structure requise a été changée incorrectement.

Flux global

1. L'admin crée ou vérifie un modèle de notification de base.
2. L'admin définit le titre, le contenu, les variables, la catégorie, la priorité et le statut.
3. L'admin crée des versions localisées pour les langues et objectifs nécessaires.
4. L'admin marque la bonne version localisée comme version par défaut si nécessaire.
5. Les flux automatiques utilisent le modèle correspondant lors de l'envoi des messages.
6. Les utilisateurs reçoivent la notification dans le canal et la langue appropriés lorsque disponibles.