OBLYTECH Logo
Enquire Now
OBLYTECH Logo

ServiceNow / Practical guide

ServiceNow Communication Preferences: Govern the Right Channel

ServiceNow communication preferences should help users receive the information they need through an appropriate channel without hiding a material service or safety condition. Governance covers purpose, audience, urgency, access, preference, escalation, exception, and review.

For ServiceNow service owners deciding how users should receive operational, request, and service communications..

ServiceNow communication preferencesnotification preferencescommunication channels
Discuss this ServiceNow topic

Guide map

Deciding which channel each notice should use

Define the purpose of each communication

Each message to users should answer one question they would otherwise have to ask someone, and it should say what, if anything, they need to do next.

Match channel to urgency and audience

Send urgent outage notices through the channel people already watch, and keep routine service updates in a place they can review at their own pace.

Respect access and preference boundaries

A preference should never override a permission check, so a user who cannot see a record should not receive an alert about it through any channel.

The practical framework

Govern ServiceNow communication preferences with audience, purpose, channel, urgency, consent, access, escalation, exceptions, and review evidence.

Define the purpose of each communication

State whether the message confirms a request, asks for a decision, warns of risk, communicates an interruption, or provides guidance. The purpose determines what information is necessary and whether a preference can change delivery.

The ServiceNow notification route is the relevant internal destination when message triggers need design.

Match channel to urgency and audience

Choose the channel, timing, audience, owner, and escalation for the condition. A routine update and an urgent service warning should not be treated as the same communication. Consider whether the recipient can act through the chosen channel.

The ServiceNow user-adoption route provides an internal path when users need communication guidance.

Respect access and preference boundaries

Record what the user can change, which messages require a preference, what data the channel exposes, and which role or service owns the decision. Do not use preferences to bypass access control or disclose unnecessary information.

The ServiceNow privacy-operations route is relevant when communication contains controlled information.

Preserve escalation for material conditions

Define the condition that overrides a routine preference, who approves the override, what evidence supports it, and how it is communicated. An exception should be narrow, documented, and reviewable.

The ServiceNow incident-management route supports communication during service-impacting events.

Review missed or ineffective communication

Review wrong recipients, missed updates, repeated messages, inaccessible content, preference conflicts, and escalation outcomes. Assign the correction to the message, channel, access rule, process, or ownership boundary that caused the issue.

For communication preferences governance work, the ServiceNow continuous-improvement route provides the next internal path.

Common questions

Questions teams ask about communication preferences

Can users opt out of every message?

Not necessarily. Preferences can govern eligible communications, but material service, security, safety, or process messages may require a defined exception and access boundary.

What should override a preference?

Only a defined condition with a clear authority, evidence, purpose, channel, and review path should override a preference. The override should not become a general communication shortcut.

The research-grounded boundary

The research supports a cautious conclusion for ServiceNow communication preferences. ServiceNow platform may provide platform context, but a controlled access or governance decision still needs an explicit contract for inputs, decisions, exceptions, and review. That is the part most likely to be missed when a team focuses only on the visible feature. The communication preferences governance reader can use that distinction to decide what belongs in configuration, what belongs in governance, and what belongs in support.

Separate messages users can switch off from messages they cannot

Preference settings in a ServiceNow instance are easy to add and hard to reason about. Once a user can switch off one notification, someone will ask whether they can switch off all of them, and the answer decides whether an outage warning, a security instruction or an approval reminder can be silenced by one click. The decision for the service owner is the list of message classes that are mandatory, the list that is optional, and who may change either list. Settle that before any preference screen is built, and read the notification concepts if the terms are new, because the screen will otherwise become the policy.

Classify every message before offering a choice

Message classTypical examplesCan the user opt out?Who sets the rule
Safety and securityCredential compromise notices, lock-down instructionsNoSecurity owner
Service interruptionMajor incident updates, planned outage windowsNo, but the channel can changeService owner with the incident manager
Decision requiredApproval requests, attestations dueChannel only, never the message itselfProcess owner
Request progressStatus changes, resolution noticesYes, with a digest optionRequester’s service owner
Guidance and newsNew catalog items, knowledge highlightsYesCommunications owner

The table is a starting point and each organization will move rows. For the service interruption row, the major incident communication page is the related pointer. What matters is that a class is assigned before the first preference is saved, and that a change to a class goes through the same owner who signed off the original decision. A message moved from optional to mandatory should trigger a review of the people who can no longer switch it off.

Channel is a different decision from content

A user who turns off email for request status messages may still want the same message in the portal, or as a single daily digest. Treat channel preferences as the user’s choice inside the rules, and treat content as the service’s decision. The notification governance guide is the related pointer for governing messages around the action they ask for. Where a message is urgent, the platform should send it through every permitted channel rather than waiting for the user to notice a banner. For each class, ask which channel a person would actually see at the moment the message matters. For an out-of-hours outage, that may be a mobile channel, not the inbox they read on Monday.

How preferences go wrong in practice

  • A preference is applied at group level and silently covers members who should have received a mandatory notice.
  • Several notification rules fire for one event, so a user receives three copies and switches the whole category off.
  • A template is edited by a communications team without anyone checking which rules send it.
  • An integration to a chat tool sends messages that bypass the platform’s own preference check.
  • Nobody reviews suppressed messages, so a mandatory notice that failed to deliver goes unnoticed for weeks.

A sequence for putting the governance in place

  1. Inventory every notification rule and the template it sends, with a named owner against each.
  2. Assign each rule to a message class and mark which classes are mandatory.
  3. Decide which preference controls users see and which are set by administrators, then remove any control that would switch off a mandatory class.
  4. Test delivery for each class with a user who has chosen every available opt-out, and record what arrived and where.
  5. Set a review cadence for the rule inventory, and assign someone to check suppressed and failed deliveries for mandatory classes.

Signs the governance is working

Good governance shows as quiet, not as an absence of complaints. Users should be able to find the setting that explains a message they receive, and support staff should be able to say why a particular person did or did not receive a particular notice. Track complaints about duplicate or missing messages, and compare them with the expectations set in the service level communication guide, and track opt-out patterns by class. A class where opt-outs climb steadily can be a class that is sent too often or in the wrong channel, not one users simply dislike. The user adoption and training page is the related pointer for preparing support staff.

When to leave preferences out altogether

Some messages are better sent without any preference at all. A small set of notifications may not justify a preference center, which adds maintenance and little value. Leave it out until the notification count and the number of rule owners make the effort worthwhile, and document the reasons so the question does not return every review cycle.

Preference questions from service teams

Should a manager be able to switch off notifications for their team?

Only for optional classes, and only through a documented route. A team-level setting that a manager can change without a record makes it impossible to explain later why an employee missed a notice.

How do we handle a user who says they were never notified of a change?

Check the delivery record for that user and that event first. Many of these cases come down to a channel the user had disabled, a rule that never matched, or a mail filter outside the platform, and each has a different fix.

Do preferences apply to integrations?

They should, and by default they often do not. Any integration that sends messages on behalf of the platform needs its own check against the same class rules, or it becomes an unmanaged channel.

Next step on notification governance

If your preference settings are growing faster than the rules behind them, a short review of message classes and owners is the most useful place to start, beginning with the current list of notification rules and the owner of each.

A practical next step

Need a clearer ServiceNow operating model?

OBLYTECH can discuss the questions raised by this guide and the next review step. See the ServiceNow consulting services page for the commercial route.

Useful starting pointBring the current question, scope, ownership concerns, and evidence needs into the first review conversation.

Review ServiceNow consulting

ServiceNow guides on this topic

Guides from the Oblytech ServiceNow library that explain the practice behind this page.

More from the blog

Related reading