Email notifications that fire too often or at the wrong time create noise for users and make important messages easy to miss. This guide shows you how to stop notifications temporarily or permanently using three different approaches.
Why email notifications need control mechanisms
Notifications that seemed reasonable during development often become problems in production. A notification that fires on every incident update floods the help desk with messages. A notification tied to a workflow that runs more often than expected overwhelms stakeholders. The people affected — end users, assignees, and managers — start ignoring all emails from ServiceNow when the noise level gets too high. Platform admins need quick ways to shut off problematic notifications without losing the configuration work.
Three ways to control notification delivery
ServiceNow gives you three control points: the notification record itself (Active checkbox), individual user preferences (subscriptions), and instance-wide email redirection (glide.email.test.user property). The Active checkbox is the master switch — uncheck it and the notification stops firing for everyone immediately. User subscriptions let individuals opt out while keeping the notification active for others. The test property redirects all outbound email to a single address, useful when you're troubleshooting or working in a development instance.
Managing notifications long-term
Once you've stopped the immediate problem, the next step is understanding why the notification fired too often. Most notification problems stem from conditions that are too broad, missing field-level change detection, or business rules that update records more frequently than expected. A well-managed notification strategy includes regular audits of active notifications, clear naming conventions so you can find notifications quickly, and test data that validates notifications fire only when intended.
Before you start
- •admin role or notification_admin role
Sourdough: ServiceNow Monitoring and Analytics
A Chrome extension for ServiceNow Admins and Developers with essential tools, analytics, graphs and monitoring features.
Free to install. Pro $5/month after a 14-day no-card trial.
Pro requires the ServiceNow admin role. Upgrade inside the extension.
Step by step
Navigate to the notification record
Go to System Notification > Email > Notifications. Use the search bar to find the notification by name, or filter by Table if you know which table triggers it. Click the notification name to open the record. The notification name appears in the Name field at the top of the form.
If you're not sure which notification is causing problems, check the Email Logs table first to see which notifications have been sending recently.
Deactivate the notification
Uncheck the Active checkbox in the notification record. This immediately stops the notification from firing for all users. Click Update to save the change. The notification will remain in the system with all its configuration intact, but won't send any emails until you reactivate it.
Add a note in the Additional Comments field explaining why you deactivated it — your future self will thank you.
Check user subscription settings
Scroll to the Subscriptions related list at the bottom of the notification record. This shows individual users who have opted out of this notification. Users appear here when they click the unsubscribe link in an email or manually opt out through their preferences. These users won't receive the notification even when it's active.
If key stakeholders aren't getting emails, check if they accidentally unsubscribed before assuming the notification is broken.
Set up email redirection for testing
Navigate to System Properties > Basic Configuration. Search for 'glide.email.test.user' and click the property name. Enter an email address in the Value field and click Update. This redirects ALL outbound email from the instance to that address, regardless of notification settings. Leave the Value field empty to restore normal email delivery.
Verify the notification status
Create or update a record that should trigger the notification. If you deactivated it, no email should send. If you set the test property, the email should arrive at your test address instead of the intended recipients. Check System Notification > Email > Email Logs to confirm the notification fired or didn't fire as expected.
Document your changes
If this is a temporary fix, create a reminder to investigate and reactivate the notification. Add a calendar item or task with details about what you changed and why. Include the notification sys_id so you can find it quickly later. For permanent deactivation, document the business reason in the notification's Additional Comments field.
Best practices
Never delete notification records to stop them — deactivate them instead so you preserve the configuration and can reactivate if needed.
Use the glide.email.test.user property in development and test instances to prevent accidentally sending emails to real users during testing.
When users unsubscribe from notifications, they're opting out individually — this doesn't affect other users, unlike deactivating the notification itself.
Check the Email Logs table regularly to catch notifications that are firing too frequently before users start complaining.
Clear the glide.email.test.user property after testing — leaving it set means production emails go to your test address instead of real users.
Test Your Knowledge
Quick 3-question quiz — see how your ServiceNow skills stack up.
A list view on a table with millions of records is slow. Best fix?
Select an answer to continue