ServiceNow propose, avec Targeted Communications, un mécanisme permettant de créer des publications destinées à des utilisateurs ou à des groupes de destinataires ciblés.

Une publication peut notamment être accompagnée d'une notification email. Lors de la création d'une publication, l'interface permet de désactiver la notification ou de sélectionner un Email Template qui sera utilisé pour l'envoi.

Sur le papier, cela semble offrir une certaine flexibilité : il devrait être possible de créer plusieurs templates et de choisir celui correspondant au besoin de chaque publication.

Cependant, dans un environnement principalement ITSM, cette possibilité est en réalité limitée.

Le problème vient d'une dépendance au plugin Customer Service Management (com.sn_customerservice) présente dans le code standard de ServiceNow.

Autrement dit, le champ Email Template existe dans l'expérience Targeted Communications, mais le mécanisme permettant réellement d'utiliser ce template pour générer la notification est conditionné à l'activation de CSM.

Targeted Communications et le champ Email Template

La documentation ServiceNow indique que lors de la création d'une publication, il est possible d'inclure une notification email et de sélectionner un Email Template.

Le champ Skip Notification permet de désactiver la notification. Lorsqu'il est sélectionné, le champ Email Template est désactivé et les options liées aux pièces jointes disparaissent.

La documentation décrit donc bien le champ Email Template comme un élément permettant de choisir le template utilisé pour envoyer l'article aux destinataires.

Documentation ServiceNow - Create a publication

Le problème apparaît lorsqu'on regarde ce qui se passe réellement côté serveur.

Le rôle de RecipientsListApi

Le traitement des destinataires et de la notification est notamment effectué par le Script Include :

sn_publications.RecipientsListApi

et plus précisément par la fonction :

buildRecipientsListForPublication().

Cette fonction commence par récupérer la publication :

var publicationGr = new GlideRecord('sn_publications_publication');

if (!publicationGr.get(publicationSysId)) {
    gs.error("RecipientsListApi::buildRecipientsListForPublication: Invalid publication id:" + publicationSysId);
    return;
}

Elle vérifie ensuite si le plugin CSM est actif :

var isCSMActive = GlidePluginManager.isActive('com.sn_customerservice');

Cette variable va jouer un rôle déterminant dans la création et la mise à jour de la notification.

Le fonctionnement de Skip Notification

Le comportement de Skip Notification est relativement simple.

Le code récupère la valeur du champ :

if (publicationGr.getValue('skip_notifications') == 0)
    emailNotification = true;

Ainsi :

• skip_notifications = false → une notification doit être utilisée ;

• skip_notifications = true → aucune notification n'est créée ou mise à jour.

Cela correspond au comportement décrit dans la documentation officielle.

Mais le point intéressant arrive juste après.

Le template est bien récupéré...

Lorsque la notification doit être utilisée, le code récupère le template sélectionné dans la publication :

var template = publicationGr.getValue('target_email_template');

On pourrait donc naturellement s'attendre à ce que ServiceNow crée une notification en utilisant ce template.

Et c'est effectivement ce que le code essaie de faire.

Le problème est la condition qui entoure cette opération.

...mais la création de la notification dépend de CSM

Le code récupère d'abord une éventuelle notification déjà associée à la publication :

var notificationId = publicationGr.getValue('notification');

Puis, si aucune notification n'existe, ServiceNow prépare les paramètres nécessaires :

if (!notificationId) {
    var name = publicationGr.getValue('number') + " notification";
    var collection = "sn_publications_publication";
    var generation_type = "engine";
    var action_update = true;

    var condition =
        "sys_id=" + publicationSysId +
        "^stageCHANGESTOpublished" +
        "^skip_notifications=false" +
        "^target_email_templateISNOTEMPTY^EQ";

Jusqu'ici, rien de particulièrement surprenant.

Mais la création de la notification est ensuite protégée par :

if (isCSMActive) {
    notificationId = new global.PublicationUtils()
        .createEmailNotification(
            name,
            collection,
            generation_type,
            action_update,
            condition,
            template
        );

    publicationGr.setValue('notification', notificationId);
}

C'est ici que se trouve la limitation.

Sans CSM

Si :

GlidePluginManager.isActive('com.sn_customerservice')

retourne false, alors :

new global.PublicationUtils().createEmailNotification(...)

n'est jamais exécuté.

Le template sélectionné dans :

target_email_template

est bien présent sur la publication, mais aucune notification n'est générée à partir de celui-ci par ce code standard.

Avec CSM

Lorsque le plugin CSM est actif, ServiceNow appelle :

PublicationUtils.createEmailNotification(...)

et lui transmet notamment le template sélectionné :

template

La notification est alors créée et associée à la publication via le champ :

notification

Une notification est créée pour chaque publication

Un autre détail intéressant se trouve dans cette logique.

Le nom de la notification est construit à partir du numéro de la publication :

var name = publicationGr.getValue('number') + " notification";

Cela signifie que ServiceNow ne semble pas simplement utiliser une notification globale unique pour toutes les publications.

Lorsqu'une publication n'a pas encore de notification associée :

if (!notificationId)

une nouvelle notification est créée.

La notification est ensuite stockée sur la publication :

publicationGr.setValue('notification', notificationId);

On obtient donc conceptuellement une relation :

Publication
     │
     └── Notification
             │
             └── Email Template

Chaque publication peut ainsi avoir sa propre notification et son propre template.

C'est précisément ce mécanisme qui permettrait d'avoir plusieurs publications avec des templates différents.

Et si la publication possède déjà une notification ?

Le code prévoit également le cas où une notification existe déjà :

else if (isCSMActive) {
    new global.PublicationUtils()
        .updateEmailNotification(notificationId, template);
}

La notification existante est alors mise à jour avec le template actuellement sélectionné.

On retrouve donc deux opérations :

Publication sans notification
        ↓
createEmailNotification()
        ↓
Notification créée

et :

Publication avec notification
        ↓
updateEmailNotification()
        ↓
Notification mise à jour

Mais dans les deux cas, le traitement est conditionné par :

isCSMActive

Une dépendance à CSM qui limite l'utilisation dans ITSM

C'est à ce niveau que l'on comprend réellement la limitation pour un environnement ITSM.

Targeted Communications permet bien de sélectionner un Email Template lors de la création d'une publication. Le champ est présent dans l'interface et le template sélectionné est bien enregistré sur la publication.

Cependant, la sélection du template ne suffit pas à elle seule à générer la notification. Lors de la publication, RecipientsListApi doit créer ou mettre à jour la notification associée à la publication.

Or, ces deux opérations sont explicitement conditionnées par l'activation du plugin CSM :

if (isCSMActive) {
    notificationId = new global.PublicationUtils()
        .createEmailNotification(
            name,
            collection,
            generation_type,
            action_update,
            condition,
            template
        );
}

et, lorsqu'une notification existe déjà :

else if (isCSMActive) {
    new global.PublicationUtils()
        .updateEmailNotification(notificationId, template);
}

Ainsi, dans une instance où com.sn_customerservice n'est pas actif, le code récupère bien la valeur de target_email_template, mais ne va pas jusqu'à la création ou à la mise à jour de la notification par PublicationUtils.

C'est ce qui crée une différence importante entre ce que l'interface de Targeted Communications laisse penser et ce que le traitement standard permet réellement de faire dans un environnement ITSM.

Pour une organisation qui souhaite utiliser Targeted Communications uniquement pour des communications ITSM internes, cela signifie que le mécanisme standard de sélection et d'utilisation de templates d'email n'est pas entièrement disponible sans CSM.

Autrement dit, le champ Email Template existe, mais le mécanisme standard qui permet d'exploiter ce choix lors de la publication dépend de CSM.

Cette dépendance peut donc devenir un point bloquant lorsqu'on souhaite utiliser Targeted Communications dans ITSM sans installer le plugin Customer Service Management.

Pourquoi cette dépendance est problématique

Cette dépendance peut être particulièrement gênante pour une organisation qui souhaite utiliser Targeted Communications dans un contexte ITSM sans implémenter CSM.

Imaginons par exemple trois communications :

Publication 1 - Maintenance

Subject:
Planned maintenance on ServiceNow

Template:
IT Maintenance Notification

Publication 2 - Incident majeur

Subject:
Major incident communication

Template:
Major Incident Notification

Publication 3 - Nouvelle fonctionnalité

Subject:
New ServiceNow functionality available

Template:
New Feature Notification

L'objectif est naturellement de pouvoir sélectionner un template différent pour chaque publication.

La structure de Targeted Communications semble justement permettre ce fonctionnement.

Cependant, sans CSM, le code standard présenté précédemment ne passe pas dans :

PublicationUtils.createEmailNotification()

ou :

PublicationUtils.updateEmailNotification()

puisque les deux opérations sont protégées par la vérification du plugin.

Pourquoi CSM débloque la fonctionnalité

La dépendance n'est donc pas simplement une dépendance d'interface.

CSM apporte notamment les composants nécessaires à la gestion de la notification de Targeted Communications, dont PublicationUtils est utilisé ici pour créer ou mettre à jour la notification.

Le code fait explicitement le choix de ne déclencher ces opérations que lorsque :

com.sn_customerservice

est actif.

Cela crée une situation assez particulière :

Targeted Communications peut être utilisé dans un contexte plus large, mais la personnalisation du template d'email via le mécanisme standard de publication est conditionnée à l'activation de CSM.

C'est une distinction importante lorsqu'on évalue la fonctionnalité pour un environnement ITSM.

Ce qu'il faut retenir

Si votre objectif est uniquement d'utiliser Targeted Communications pour des communications ITSM internes, il faut être attentif à cette limitation.

Le champ Email Template est bien disponible dans la création d'une publication, et la documentation officielle indique qu'il permet de sélectionner le template utilisé pour la notification.

Cependant, le code standard de RecipientsListApi montre que :

1. Skip Notification détermine si une notification doit être utilisée.

2. Le template sélectionné est récupéré depuis target_email_template.

3. Une notification est créée pour la publication si aucune notification n'existe.

4. Une notification existante peut être mise à jour avec un nouveau template.

5. La création et la mise à jour de cette notification ne sont exécutées que lorsque le plugin com.sn_customerservice est actif.

Ainsi, dans un environnement ITSM sans CSM, le choix du template d'email est limité par cette dépendance standard.

Conclusion

Targeted Communications est une fonctionnalité intéressante pour envoyer des communications ciblées depuis ServiceNow. La possibilité de choisir un Email Template directement depuis une publication donne l'impression qu'il est possible de personnaliser facilement le contenu des notifications.

Mais lorsqu'on analyse l'implémentation serveur, on découvre une dépendance importante envers Customer Service Management.

Le point clé est cette simple vérification :

var isCSMActive =
    GlidePluginManager.isActive('com.sn_customerservice');

suivie de :

if (isCSMActive) {
    new global.PublicationUtils()
        .createEmailNotification(...);
}

et :

else if (isCSMActive) {
    new global.PublicationUtils()
        .updateEmailNotification(...);
}

Pour une implémentation ITSM, cela signifie que l'activation de CSM devient nécessaire pour débloquer le mécanisme standard de création et de personnalisation des notifications de Targeted Communications.

Cette dépendance mérite donc d'être prise en compte avant de considérer Targeted Communications comme une solution complète de communication email dans un environnement ITSM.

Targeted Communications - Documentation ServiceNow

Create a publication - Documentation ServiceNow