Tester, publier et exploiter les communications

01Le catalogue relie le contenu au métier #sec_eb7a12db

Ouvrez Paramètres > Communication > Catalogue de mails .

Un modèle n'est pas seulement une mise en page. Il est associé à un événement métier, une langue, un état de publication et, lorsqu'il existe plusieurs variantes, un modèle par défaut. Le catalogue permet ainsi de faire évoluer le contenu sans modifier le fonctionnement d'une campagne.

Les modèles globaux fournis par REVIEWIT servent de socle. La souscription peut les copier dans son catalogue pour créer une variante gouvernée localement. La copie devient alors un modèle autonome : elle peut être adaptée, testée puis publiée sans altérer la référence globale.

02Comprendre le choix du modèle #sec_3b7d052a

Lors d'un envoi automatique, REVIEWIT cherche d'abord le modèle local publié qui correspond à l'événement et à la langue. À défaut, il utilise la référence de plateforme dans cette langue, puis sa variante anglaise. Une ressource anglaise intégrée assure le dernier repli pour les événements structurels.

Le statut Publié autorise l'usage. Le statut Par défaut est également opérationnel : un modèle publié qui n'est pas la variante par défaut de son couple événement-langue ne sera pas choisi automatiquement.

03Utiliser les variables #sec_06b16195

Les variables injectent le contexte réel dans le modèle. Leur syntaxe est sensible à la casse et utilise une seule paire d'accolades : {CampaignTitle} , {ResourceName} ou {ReviewerName} , par exemple.

Elles peuvent être utilisées dans le sujet, le pré-en-tête, le corps et les attributs HTML. Dans un fichier HTML, le contenu de <title> devient également le sujet du message. Les valeurs sont encodées afin qu'un texte contenant < ou & ne puisse pas modifier le HTML.

Une variable sans valeur reste visible telle quelle dans le courriel. C'est un signal d'erreur utile lors du test, mais il ne doit pas atteindre les destinataires. La casse compte : {ResourceName} et {resourcename} sont deux identifiants différents.

04Variables disponibles par événement #sec_9bbe09a2

La liste suivante donne les variables sûres à employer dans les modèles actuellement émis. Un événement marqué Dormant est connu du catalogue, mais n'est pas encore déclenché automatiquement.

La fiche [Variables des courriels : référence et exemples](tuto-communication-factory-variables) regroupe séparément la syntaxe, le dictionnaire détaillé et les contrôles à effectuer.

Revues

EscalationReceived possède plusieurs chemins d'émission. Certains fournissent aussi EscalatedByName et Reason , d'autres CampaignId et DueDate . Seul ResourceName est garanti dans tous les cas : utilisez cette intersection dans le modèle par défaut.

Contestations et décisions

Suppressions, accès et consultation

05Choisir une présentation adaptée à la variable #sec_62b17f16

ResourceName peut être un nom lisible ou une référence comme #123 . Présentez-le dans un bloc étiqueté plutôt que dans une phrase qui suppose qu'il s'agit toujours d'un nom.

Les dates sont déjà formatées par le service qui émet l'événement. Ne tentez pas de les reformater dans le HTML.

Answer , Question , Reason , Argument , Comment et ResolutionNote sont des textes libres saisis par des personnes. Affichez-les comme des citations ou dans un bloc dédié, jamais à l'intérieur d'une phrase dont ils pourraient changer le sens.

CampaignId est un identifiant numérique. Utilisez CampaignTitle lorsqu'il est proposé et que le modèle a besoin d'un titre lisible.

06Variables à ne pas utiliser pour le moment #sec_8cd304e6

{DeepLink} et {SettingsLink} apparaissent encore dans certains modèles historiques, mais elles ne sont pas alimentées par les événements actuels. N'ajoutez pas de bouton ou de lien qui en dépend tant qu'elles ne figurent pas parmi les variables disponibles de l'événement.

Certaines relances manuelles historiques emploient encore la syntaxe {{ReviewerName}} . Elle n'est pas équivalente à la syntaxe {ReviewerName} des notifications automatiques. Testez toujours le modèle dans le parcours qui l'utilisera réellement.

07Prévisualiser et envoyer un test #sec_47ce789e

Avant de publier :

1. ouvrez l'aperçu du modèle ;
2. vérifiez le sujet, le pré-en-tête et la mise en page ;
3. fournissez des valeurs réalistes à toutes les variables présentes ;
4. choisissez un expéditeur actif ;
5. envoyez le message vers une adresse contrôlée ;
6. vérifiez qu'aucun texte {Variable} ne subsiste dans le message reçu.

Un envoi accepté prouve que la chaîne REVIEWIT-fournisseur fonctionne. Il ne prouve pas à lui seul la livraison en boîte de réception, l'ouverture du message ni l'action du destinataire.

08L'assistance attendue dans l'éditeur #sec_6baa51e4

Cette référence a vocation à alimenter directement l'éditeur : lorsque l'administrateur choisit un événement, une palette Variables disponibles peut afficher uniquement les variables pertinentes, leur définition et un exemple, puis permettre de les insérer au curseur.

La validation peut alors signaler avant l'envoi :

• une variable garantie, prête à être utilisée ;
• une variable contextuelle, absente de certains chemins ;
• une variable inconnue ou indisponible ;
• une syntaxe incorrecte, notamment les doubles accolades ;
• une variable présente dans le HTML mais sans valeur de test.

La page que vous lisez reste la référence fonctionnelle : elle permet de préparer et de contrôler un modèle, y compris lorsque cette aide contextuelle n'est pas encore proposée par l'éditeur utilisé.

09Publier avec discernement #sec_f4bd4f8e

Publiez uniquement les variantes prêtes à être utilisées. Pour chaque événement et chaque langue nécessaires, contrôlez qu'un seul modèle publié porte le statut par défaut.

Un modèle associé à un événement dormant peut être prévisualisé et testé, mais il ne sera pas envoyé automatiquement tant que la fonction métier correspondante ne l'émet pas.

10Exploitation quotidienne #sec_e7735df5

La configuration est prête lorsque les cinq éléments suivants sont réunis :

• une route d'envoi active et désignée par défaut ;
• un domaine vérifié puis activé ;
• un expéditeur actif et cohérent avec cette route ;
• un modèle publié et par défaut pour l'événement et la langue ;
• un test reçu sans variable non résolue.

Après toute rotation de secret, modification DNS ou changement de route, refaites un test complet. Gardez également un œil sur les quotas, les rejets et les retours de délivrabilité du fournisseur : une demande d'envoi acceptée n'est pas une preuve de remise.

11À retenir #sec_f6d8bee2

Le catalogue gouverne le sens du message ; les domaines et les expéditeurs en établissent la légitimité ; le fournisseur en assure la remise. Le Subscription Manager rassemble ces leviers sans confondre leurs responsabilités.