The CreatorCon Call for Content is officially open! Get started here.

Looking for any information on Notification Best Practices

LaniStover
Kilo Contributor

Hello,

i'm looking for any information on notification best practices including the use of templates, events, maintenance and format for IT and non IT business partners.  

Appreciate any information...

4 REPLIES 4

Uncle Rob
Kilo Patron

Sure!   In no particular order



CONFIGURATION


  • First, understand the Email Accounts table.   If you're using ServiceNow beyond IT, the default settings are going to look strange, because every email from ServiceNow will look like its from "IT Service Desk"
  • Remember, on each notification you can configure a "from" (both a specific address and an alias).   This can come in *really* handy when dealing with non-IT stakeholders, or involving 3rd parties outside your organizations into your workflow.


CONTENT


  • Only send email if you *must*.   Make good homepages end encourage tool participation
  • Focus on maximizing content in the Subject lines of any notification.   With the volume of notifications SN instances usually sends, I find most users *hate* having to click into them.   If you're not embedding content into subject line, you are intentionally wasting someone else's time.


WORKFLOWS / EVENTS


  • Event driven notifications are a little more effort to set up and manage, but well worth it for the extra layer of troubleshooting it gives AND the ability to fire them via script or workflow
  • Don't bother with the Notification activity in Workflow.   Its fast, but harder to manage / troubleshoot.   Its far better to create a notification record that's event driven, then trigger the event from the workflow.


INBOUND EMAIL


  • Memorize this diagram:   Inbound Email Actions - ServiceNow Wiki
  • Actively discourage the use of Inbound Email as a mechanism for ticket creation.   It should only be used when the sending party is a robot.   Over time, the conditions desired by your stakeholders, and the propensity for user input error will make inbound email a horrific mess.   Its also like Pandora's Box. Once you tell users they can email into ServiceNow, they'll never stop.   I force stakeholders to sign off to knowing about a 30% failure rate if they want inbound email processing.


And the single most important rule when dealing with notifications in ServiceNow...


NEVER expose <company>@servicenow.com.   ALWAYS have your own company address that passes to your @servicenow.com address.   I can spend an entire thread expressing how absolutely FiretrUCKING crucial this is.   But short version is as follows.


  • Once you tell people about an email address, they'll never forget.   Never.
  • You don't own your @servicenow.com address.   You only rent it.
  • When people submit suicide notes, sexual harassment complaints, whistle-blowing, compliance killing PII, and other scary content (and they will - I've seen all of these at multiple companies)... you now have those stuck on a vendor's email system.   Not your own.   That can all get you in legal trouble that will dwarf the size of all your ServiceNow initiatives for the next 10 years combined.

David Hepburn
Tera Guru

re:  Inbound Email

 

The above link to Inbound Email Actions doesn't work anymore, but I did find this diagram at

https://www.servicenow.com/community/developer-forum/servicenow-learning-84-how-inbound-email-proces... 

 

SN inbound email actions.png

David Hepburn, III (he / him) | Paramedic
CSA, Senior Enterprise Application Analyst
ServiceNow DevOps
Children’s Health System of Texas
Dallas, Texas, USA

he looks a little scary... but I'll take the cookie 🙂

 

 

David Hepburn, III (he / him) | Paramedic
CSA, Senior Enterprise Application Analyst
ServiceNow DevOps
Children’s Health System of Texas
Dallas, Texas, USA