With Targeted Communications, ServiceNow provides a mechanism for creating publications targeted at specific users or recipient groups.

A publication can include an email notification. When creating a publication, the interface allows you to disable the notification or select an Email Template to be used when the notification is sent.

At first glance, this seems to provide a certain level of flexibility: you should be able to create multiple templates and select the one that best fits the purpose of each publication.

However, in an environment primarily focused on ITSM, this capability is actually limited.

The issue comes from a dependency on the Customer Service Management (com.sn_customerservice) plugin that is present in ServiceNow's standard code.

In other words, the Email Template field is available in the Targeted Communications interface, but the mechanism that actually uses this template to generate the notification is conditional on CSM being active.

Targeted Communications and the Email Template field

The ServiceNow documentation states that when creating a publication, you can enable an email notification and select an Email Template.

The Skip Notification field allows you to disable the notification. When it is selected, the Email Template field is disabled, and the options related to attachments are also hidden.

The documentation therefore clearly presents the Email Template field as the way to select the template that will be used to send the publication to its recipients.

ServiceNow Documentation - Create a publication

The issue becomes apparent when looking at what actually happens on the server side.

The role of RecipientsListApi

The processing of recipients and notifications is handled, among other things, by the following Script Include:

sn_publications.RecipientsListApi

More specifically, the relevant logic is located in the following function:

buildRecipientsListForPublication().

The function first retrieves the publication:

var publicationGr = new GlideRecord('sn_publications_publication');

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

It then checks whether the CSM plugin is active:

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

This variable plays a key role in determining whether the notification associated with the publication will be created or updated.

How Skip Notification works

The behavior of Skip Notification is relatively straightforward.

The code retrieves the value of the field:

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

Therefore:

• skip_notifications = false → a notification should be used;

• skip_notifications = true → no notification is created or updated.

This is consistent with the behavior described in the official documentation.

But the interesting part comes immediately after.

The template is retrieved...

When a notification is required, the code retrieves the template selected on the publication:

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

At this point, we would naturally expect ServiceNow to create a notification using that template.

And that is indeed what the code is designed to do.

The issue is the condition surrounding this operation.

...but notification creation depends on CSM

The code first retrieves any notification already associated with the publication:

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

Then, if no notification exists, ServiceNow prepares the parameters required to create one:

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";

So far, nothing looks particularly unusual.

However, the notification is then created only if CSM is active:

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

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

This is where the limitation becomes apparent.

Without CSM

If:

GlidePluginManager.isActive('com.sn_customerservice')

returns false, then:

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

is never executed.

The template selected in:

target_email_template

is still stored on the publication, but no notification is generated from it by this standard code.

With CSM

When the CSM plugin is active, ServiceNow calls:

PublicationUtils.createEmailNotification(...)

and passes the selected template to it:

template

The notification is then created and associated with the publication through the:

notification

field.

A notification is created for each publication

Another interesting detail can be found in this logic.

The notification name is built from the publication number:

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

This indicates that ServiceNow does not simply rely on a single global notification for all publications.

When a publication does not yet have an associated notification:

if (!notificationId)

a new notification is created.

The notification is then stored on the publication:

publicationGr.setValue('notification', notificationId);

Conceptually, the relationship looks like this:

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

Each publication can therefore have its own notification and its own template.

This is precisely the mechanism that would allow different publications to use different templates.

And what if the publication already has a notification?

The code also handles the case where a notification already exists:

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

The existing notification is then updated with the template currently selected on the publication.

There are therefore two operations:

Publication without a notification
        ↓
createEmailNotification()
        ↓
Notification created

and:

Publication with an existing notification
        ↓
updateEmailNotification()
        ↓
Notification updated

But in both cases, the operation is conditional on:

isCSMActive

A CSM dependency that limits ITSM usage

This is where the limitation for an ITSM environment becomes clear.

Targeted Communications does allow you to select an Email Template when creating a publication. The field is available in the interface, and the selected template is stored on the publication.

However, selecting a template alone is not enough to generate the notification. When the publication is processed, RecipientsListApi must create or update the notification associated with the publication.

Both operations are explicitly conditional on the CSM plugin being active:

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

And when a notification already exists:

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

Therefore, in an instance where com.sn_customerservice is not active, the code does retrieve the value of target_email_template, but it never proceeds with creating or updating the notification through PublicationUtils.

This creates an important gap between what the Targeted Communications interface appears to offer and what the standard backend implementation actually allows in an ITSM environment.

For an organization that wants to use Targeted Communications exclusively for internal ITSM communications, this means that the standard mechanism for selecting and applying email templates is not fully available without CSM.

In other words, the Email Template field exists, but the standard mechanism that makes this selection effective when the publication is processed depends on CSM.

This dependency can therefore become a blocker when using Targeted Communications in an ITSM environment without installing the Customer Service Management plugin.

Why is this dependency problematic?

This dependency can be particularly problematic for an organization that wants to use Targeted Communications in an ITSM environment without implementing CSM.

For example, imagine three communications:

Publication 1 - Maintenance

Subject:
Planned maintenance on ServiceNow

Template:
IT Maintenance Notification

Publication 2 - Major Incident

Subject:
Major incident communication

Template:
Major Incident Notification

Publication 3 - New Feature

Subject:
New ServiceNow functionality available

Template:
New Feature Notification

The goal would naturally be to select a different template for each publication.

The structure of Targeted Communications appears to support exactly this type of configuration.

However, without CSM, the standard code described above never reaches:

PublicationUtils.createEmailNotification()

or:

PublicationUtils.updateEmailNotification()

because both operations are protected by the plugin check.

Why does CSM unlock the functionality?

The dependency is therefore not simply an interface dependency.

CSM provides, among other things, the components required to manage Targeted Communications notifications, with PublicationUtils being used here to create or update the notification.

The code explicitly chooses to execute these operations only when:

com.sn_customerservice

is active.

This creates a rather interesting situation:

Targeted Communications can be used in a broader context, but customizing the email template through the standard publication mechanism is conditional on CSM being active.

This is an important distinction to keep in mind when evaluating the feature for an ITSM environment.

What should you take away?

If your goal is solely to use Targeted Communications for internal ITSM communications, this limitation should be taken into account.

The Email Template field is indeed available when creating a publication, and the official documentation indicates that it allows you to select the template used for the notification.

However, the standard RecipientsListApi code shows that:

1. Skip Notification determines whether a notification should be used.

2. The selected template is retrieved from target_email_template.

3. A notification is created for the publication if no notification exists.

4. An existing notification can be updated with a new template.

5. The creation and update of this notification are only executed when the com.sn_customerservice plugin is active.

Therefore, in an ITSM environment without CSM, the choice of email template is limited by this standard dependency.

Conclusion

Targeted Communications is an interesting feature for sending targeted communications from ServiceNow. The ability to select an Email Template directly from a publication gives the impression that it should be possible to easily customize the notification content.

However, when analyzing the server-side implementation, we discover an important dependency on Customer Service Management.

The key point is this check:

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

followed by:

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

and:

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

For an ITSM implementation, this means that activating CSM is required to unlock the standard mechanism for creating and customizing Targeted Communications notifications.

This dependency should therefore be taken into account before considering Targeted Communications as a complete email communication solution in an ITSM environment.

Targeted Communications - ServiceNow Documentation

Create a publication - ServiceNow Documentation