Workplace Notifications Reference – Case Management & Reservation Management

Lalit Bhatt · 3 weeks ago

If you’re working with Workplace Case Management or Workplace Reservation Management, it’s often useful to know which notifications exist, when they are triggered, and who receives them.

To make this easier, I’ve compiled and attached a reference list of out-of-the-box notifications for both modules.

Important:
The notification names listed in attachments may not exactly match the notification names in your ServiceNow instance.

For example, some notifications in your instance may include “PL” in the name, which indicates that ServiceNow Polaris branding has been applied.

While the names may vary, the business purpose, trigger conditions, and recipients remain the same.

Workplace Reservation Management – Notifications Overview

The attached Workplace Reservation Management Notifications list covers notifications related to:

Reservation creation, updates, and cancellations
Recurring and series reservations
Reservation rejections and cancellations
Notifications sent to:
- Requesters
- Invitees
- Other related stakeholders

Each notification entry includes:

Notification name
Scenario in which it is triggered
Whether it is active
Target table (for example, sn_wsd_rsv_reservation)
Reservation type (single, recurring, parent, etc.)
Recipients
Steps to reproduce / generate the notification
Technical trigger details (event fired, conditions)

This is especially helpful when:

Validating expected behavior
Troubleshooting “missing” notifications
Deciding whether to customize or extend existing notifications

Attached file: Workplace Reservation Management Notifications.xlsx

Workplace Case Management – Notifications Overview

The Workplace Case Management Notifications list focuses on notifications generated during the case lifecycle, such as:

Case creation and updates
Assignment and reassignment
Status or state changes
Notifications sent to:
- Case callers
- Assignees
- Assignment groups

Each notification entry includes:

Notification name
Active status
Target table
Recipients
Steps to trigger the notification
Functional description

This reference is useful for:

Understanding default communication behavior
Auditing notification coverage
Avoiding duplicate or unnecessary custom notifications

Attached file: Workplace Case Management Notifications.xlsx

Why This Reference Is Useful

Helps admins and developers quickly understand OOTB notifications
Reduces time spent searching through Notification [sysevent_email_action] records
Useful during implementations, upgrades, or troubleshooting
Acts as documentation for functional and technical teams

Note:
These lists reflect out-of-the-box notifications. Your instance may differ if notifications have been customized, disabled, or extended.

If this reference helped you better understand Workplace notifications, please mark this post as helpful 👍

nishant3101

Thanks for putting this together—this is a very practical reference, especially for admins who struggle to trace OOTB notifications across Workplace modules in ServiceNow.

A few questions that might help others (and spark more discussion):

Scope & versioning
- Which ServiceNow release(s) did you validate these notification lists against (e.g., Vancouver, Washington)?
- Have you noticed any changes or additions across recent upgrades?
Event vs condition-based triggers
- For Workplace Reservation Management, are most notifications event-driven, or did you find some relying mainly on condition checks?
- Any tricky cases where the event fires but the notification doesn’t send due to conditions?
Polaris (“PL”) naming
- Apart from the naming difference, did you observe any functional behavior change with Polaris-enabled notifications?
- Would you recommend admins rely on trigger logic rather than names when auditing?
Common customization patterns
- In real projects, which notifications do you most often see customized or disabled?
- Any notifications you feel are redundant or commonly lead to duplicates?
Troubleshooting insights
- While compiling this, did you encounter notifications that exist but are inactive by default?
- Any tips for quickly identifying “why a notification didn’t fire” beyond checking sysevent_email_action?

Overall, this feels like something that could become a go-to checklist during implementations, upgrades, or audits. Appreciate you sharing both the functional and technical angles—very admin-friendly 👏

Would love to hear if you’re planning to extend this for other Workplace modules as well.

Lalit Bhatt

@nishant3101

Thanks for the thoughtful feedback and great questions — glad you found the reference useful! I’ll address them one by one below.

1. Scope & Versioning

Which ServiceNow release(s) did you validate these notification lists against (e.g., Vancouver, Washington)? => I validated the notification lists against Washington, Xanadu, and Yokohama releases.

Have you noticed any changes or additions across recent upgrades? =>No major differences or notable changes were observed across these releases for the notifications covered.

2. Event vs Condition-Based Triggers

For Workplace Reservation Management, are most notifications event-driven, or do some rely mainly on condition checks? => Most Workplace Reservation Management notifications are event-driven.

Any tricky cases where the event fires but the notification doesn’t send due to conditions? => Yes - a good example is the Check-in Reminder notification:

Ensure the reminder time system property is configured correctly.
Verify the scheduled job repeat interval.
If the reservation is already canceled (for example, due to no check-in), the reminder notification will not be sent.

3. Polaris (“PL”) Naming

Apart from the naming difference, did you observe any functional behavior change with Polaris-enabled notifications? => No - Polaris impacts naming and branding only. There was no functional behavior change observed.

Would you recommend admins rely on trigger logic rather than names when auditing? => Yes, absolutely. It’s far more effective to understand when and why a notification is triggered rather than focusing on the notification name itself, which may vary due to branding or customization.

4. Common Customization Patterns

In real projects, which notifications do you most often see customized or disabled? => Reservation-related notifications are the most commonly reviewed.

Any notifications you feel are redundant or commonly lead to duplicates? =>Reservation notifications can become complex - especially when:

The reservation host and “on behalf of” user are the same vs different.
The same base notification behaves differently based on the scenario.

Because of this, I strongly recommend thoroughly testing each scenario before modifying or consolidating notification content, to avoid unintended duplicates or missed messages.

5. Troubleshooting Insights

Did you encounter notifications that exist but are inactive by default? => None stood out during this exercise, but it’s always worth validating active status during audits.

Any tips for quickly identifying why a notification didn’t fire (beyond checking sysevent_email_action)?=> Yes - a very effective approach is:

Check the Events [sysevent] table to confirm whether the event was:
- Fired
- Processed
If the event exists but the notification didn’t send, it usually points to conditions, recipients, or timing-related logic rather than the event itself.

Appreciate the engagement and suggestions - I agree this can be a useful checklist during implementations, upgrades, and audits. I’m also considering extending this reference to other Workplace modules in the near future 👍