
- Post History
- Subscribe to RSS Feed
- Mark as New
- Mark as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
on 02-16-2025 10:30 PM
Articles, Blogs, Videos, Podcasts, Share projects - Experiences from the field
Hi there,
You've heard those stories right, and hopefully not encountered them yourself, where by accident email sending was enabled on a non-production instance? And what about having to enable email receiving and sending after every System Clone manually? Time to develop some tweaks for this and share it with the whole ServiceNow Community!
Failsafe Enable Email Sending
It's fairly common to activate Email Sending on non-production instances. To test emails generated, to see how emails send really look like in an email client rather than the preview in ServiceNow, etcetera. Sending email on non-production instances always does need to be treated with extreme care, you don't want test emails ending up really being send and ending up in peoples inboxes. For that it's possible to add a test email address (System Property "glide.email.test.user"). Though what if the test email address is not set and someone enables email sending... This is a scenario that I've heard of at multiple customers or happened to multiple colleagues. It just happens!
To prevent such from happening, what I have done at a few customers, is creating a "Failsafe". A failsafe that aborts activating email sending on non-production instances if the test email address is not set. An approach for this can be to create a before update Business Rule on System Property "glide.email.smtp.active" and scripted checking if it concerns a non-production instance and if the test email address is set. If not, aborting the update.
What I personally also like to do when enabling email sending on non-production instances, is emptying the ready emails in the email outbox. This would avoid thousands of pre-historical emails in the ready state to be send to the test email address, just start with a fresh email outbox!
Enable Email Receiving and Email Sending after System Clones
You probably have noticed that when performing System Clones, one of the activities after the System Clone has finished is enabling email receiving and email sending manually. A minor task to do, though why every System Clone again and again? Almost every manually post System Clone activity can be automated!
When turning the out-of-the-box Clone Cleanup Scripts inside out, one might notice that there is a Clone Cleanup Script called "Disable emails". Just deactivate this Clone Cleanup Script and we are done right? No 😀. I've tested this before also with adding Clone Data Preservers for both the email receiving and email sending System Properties, still email receiving and email sending will stay deactivated after System Clones. What exactly controls this under the hood, I don't know. I tried finding out through a ServiceNow Support Case though found no luck in that.
As alternative, at a few customers I've created a Clone Cleanup Script to enable the email receiving and email sending System Properties. For the email sending as failsafe, only if the test email address is set.
Similar like when manually enabling email sending on a non-production instance, I like to start the email outbox fresh without any ready emails. For this I also usually add a Clone Cleanup Script. In theory this Clone Cleanup Script should be redundant, though you never know... Why not just go for a Clone Exclude Tables record you might ask? Since we are enabling email sending with a Clone Cleanup Script, this will be AFTER the System Clone finishes. When a System Clone is finished, it is actually not really finished... the Clone Cleanup Scripts will still be executed, for some instances that might just take a few minutes, for other instances that could take several hours. Within that timeframe, new emails might be generated and ready in the email outbox. Therefore this extra cleanup of the send ready emails through a Clone Cleanup Script.
Share
While you can re-create the above Business Rule and Clone Cleanup Scripts, I also made this available as a Share project:
- Enable Email Sending Failsafe + Automatically Enabling After System Clones
---
That's it. A failsafe for when enabling email sending on non-production instances and eliminating a few manual post System Clone steps along the way. If any questions or remarks, let me know!
C |
If this content helped you, I would appreciate it if you hit bookmark or mark it as helpful.
Interested in more Articles, Blogs, Videos, Podcasts, Share projects I shared/participated in? |
Kind regards,
Mark Roethof
Independent ServiceNow Consultant
10x ServiceNow MVP
---
- 1,173 Views
- Mark as Read
- Mark as New
- Bookmark
- Permalink
- Report Inappropriate Content
Thanks! I have an update set with similar functionality that I deploy on almost every customer instance after talking about this risk with them. It is something that shouldn't happen, but as long as humans are involved, mistakes can be made.
I am missing one thing (also seen happening): a user is testing on non-PROD on his own email address and after testing removes his email from the property... by deleting all email addresses.
This can be fixed in several ways, all depending on the setup:
- before BR aborting the action if no email address is in (like in your example)
- before BR setting a default email address (only if available) so the property is never empty
- before BR inactivating the sending of emails when the property is empty
Even though you have to be an admin and with that it is expected that you know what you are doing, these kinds of mistakes happen and can have huge impact. Don't forget to also make sure you can't empty the 'send to' property when the sending is active.