Skip navigation

Have you noticed that some emails sent from ServiceNow never reach their destination? There are many reasons why it may seem like your emails are disappearing into cyberspace but sometimes the issue and the solution are simple.


A reason could be as simple as the emails being sent from your instance are being blocked by the end recipient's SPAM filter solution. If this is the case, depending on the configuration of the instance, a customer can guarantee that the emails arrive at their destination by whitelisting the source destinations of the emails.


An instance can be configured to send emails in two different ways.

  1. When a customer uses ServiceNow infrastructure for their SMTP configuration. This means that all SMTP traffic will be sent from ServiceNow Relay's located in each one of our DataCenters.
  2. When a customer uses their own SMTP server to relay emails to there instance users.



I will address how to whitelist emails sent from ServiceNow’s own email infrastructure.

Identify if an instance is configured to use the ServiceNow email infrastructure:


If you are using email accounts plugin it will be defined on the server field on the active SMTP record as relay, it should look like this:

service automation 1.jpg

If you are not using the email accounts plugin you can check the email property is set to relay. Also make sure your infrastructure is configured to industry standard.


When we are using ServiceNow email infrastructure we need to consider the fact that the emails will be sent from the domain even though we set the SMTP default account username to be in a different domain (


For example:


The issue here is that most email servers will consider this as Spoofing. The emails are coming from a different domain than the one we set the client to send from (, and will result in blocked emails. To make sure this email reaches its destination we need to whitelist the source of this emails to allow delivery to its recipients.


Whitelisting the IP's from ServiceNow’s relay servers would not be effective. It would result in a redundant email infrastructure that is constantly changing. Meaning that the IP addresses would be changing on a regular basis, without any pre warning from ServiceNow team.


To ensure emails from ServiceNow to be delivered at all times even when the infrastructure changes, we should be whitelisting based on the SPF records for If you speak with your email admin they can whitelist based on SPF records. If your admin is not able to do so, your only alternative would be to whitelist based on the SPF records the resolves to; however, this is a bad practice, and it is strongly not advisable, and should only be used as a last resort.


In case you are not able to whitelist based on SPF you can get the IP's addresses from resolving the SPF record and all sub SPF records, you can get this information from any web resource that resolves SPF records available on the Internet. I would suggest Sender Policy Framework (SPF) Record Lookup - SPF Check - MxToolBox.

To get your SPF records from MxToolBox:

  1. Go to Sender Policy Framework (SPF) Record Lookup - SPF Check - MxToolBox
  2. Type in the Domain name box and click SPF record lookup.
  3. Once you click the button, you will need make sure you note down all the IP addresses
  4. Repeat steps from 1 through 3 for all entries that have type include,
  5. Write down the IP's for all of the sub SPF records that are not already recorded on step 3.

spf records ip.jpg

For more information on this workaround can be found in Enabling Email Delivery Using SPF Records to Whitelist ServiceNow Email Servers (KB0535456).


Once you gather all the IP's this will be the IP's you would have to whitelist. I do not recommend this method though, this is not good practice. If you can, please please please whitelist based on SPF records. Whitelisting on SPF records is good practice as it is not subject to change like using IP addresses.


Marcio Silva
ServiceNow | Work at Lightspeed

Please mark answer as Correct, helpful as appropriate.

user interface.jpg

The Knowledge Base is kept current with frequent edits and additions. Find out what is new and stay up-to-date on the latest ServiceNow Knowledge Base articles by reviewing the weekly KB digest.




Recently added and updated articles on User Interface:




Find solutions to general ServiceNow related problems. (Click to see all General Knowledge Base articles)


User Interface (UI)

Customize, personalize and manage the way users view and interact with your organization or company’s interface using UI. (Click to see all User Interface Knowledge Base articles)



Mobile Browser

Access your ServiceNow instances and perform common tasks using the ServiceNow mobile browser. (Click to see all Mobile Browser Knowledge Base articles)


Visual Task Boards

Transform the navigation of lists and forms into an interactive graphical experience with Visual Task Boards (Click to see all Visual Task Board Knowledge Base articles)

ServiceNow has become a platform that is essential for some businesses to function by supplying a platform for common development where data can be shared. This interconnectedness fosters an environment where data is kept up to date through the daily work of the employees, directly empowering and influencing all corners of the business. To take full advantage of this environment the audience must extend beyond IT.  Once the user base has expanded to interact with more departments in the company its processes and applications must also expand to meet their needs. In this article we will start to discuss the development practices and techniques that should be employed in an environment where many users and applications are interacting; to ensure that the performance of your system is not impacted.


IT organization can drive adoption to the platform by becoming the provider of services to the company’s many groups using core applications like Service Catalog, CMS, and Knowledge. Quick access to information, services, and support can be provided through these tools with an attractive and customizable user interface.  Many times though the needs of an organization become complex and a custom component or application is needed to support their work. Application development on ServiceNow gives organizations both inside and outside of IT the ability to enhance their workflows and business processes. Efficiency and excellence in business can be empowered with this interconnected and flexible system of applications. 


A larger more diverse user base interacting with data from across the business using a variety of applications will start to put strain on the system.  Having a slow and cumbersome application impacts the speed in which the organization performs, and could impact other applications and groups that rely on their data. Structuring your applications with modularity and performance in mind will help build an environment where applications do not collide with each other. There are some key approaches that should be considered to isolate your processes and data and take advantage of the systems resources. Using asynchronous techniques in Business Rules, Script Includes, and Client Scripts will set the foundation for a scalable application environment.


Asynchronous processes can move data and instructions through the system utilizing its resources without making the user wait for those actions to complete. We keep the system busy with processing requests and allow higher priority tasks to execute that would impact other users. Large amounts of data that needs to be processed or code that needs to be executed should happen asynchronously for anything that is not required to return to the user directly. Actions such as additional record creation or field calculation can be placed into an asynchronous Business Rule. To the user these actions perform behind the scene and their page returns to them quickly and allows them to move onto their next task.


Within code we have the capability to control what we are processing utilizing events in ServiceNow. We can create custom events and handlers in the system to send data processing and instructions to be executed in the background. This is perfect for long running scripts that are not required to complete right away or might even timeout. For instance, let’s say you had large amount of records to read and transform data into another table. At some point the number of records you are looping through could make for an extremely long running process, especially if there are additional tables to look up based on each record’s information. Structuring your code to create an event for each record and a handler that will execute the transformation of that single record would allow the system to potentially process multiple records at once and not have any single process execute for too long. Eliminating long running processes on the system will help all concurrent users avoid experiencing any performance issues.

The code below is an example of what would be written to generate events for using a custom event that we have registered "record.transform" for the purposes of transforming each record individually:

//assume the records variable is a GlideRecord object
while ( {
  //the two extra parameters can be used to pass additional information like 'sys_id'
    gs.eventQueue(“record.transform”, records, records.sys_id, '');


               This is some code that would be in place to handle the "record.transform" event:

//Importing a script include that will perform the transform
var sys_id = event.parm1;
var result = new RecordTransformer().transformRecord(sys_id);
//the result here is the success or failure of the the transform
gs.log(result, 'RecordTransformResult');


Sometimes it is not just raw data processing that needs to be optimized in order to provide the user with a good experience. Inefficient client side JavaScript can present the illusion of a poor performing system. For example retrieving a record in another table from the client side would cause an additional communication to the server after the form has loaded. In most cases this could be handled with a before display Business Rule that can perform that action on the server and make it’s result available in the scratchpad to the front end. In some cases it may be necessary to wait for an interaction with the user before that data can be fetched. Enhancing fields with auto population and lookups based on the information that they are providing is a great way to enrich the user experience. In Client Scripts GlideAjax enables our ability to connect data in other parts of the system to the user’s inputs on the form. Not all Ajax performs asynchronously though, using functions like getXMLWait() with stop all functions on the form until it has received a response from the server. This is a very choppy user experience where the user perceives the system to be extremely slow. Using a call back function to update the form on the return from the server would allow the user to keep moving through the form, and the data will populate in nearly the exact amount of time without interruption.


             Here is a code example for using GlideAjax on the client side utilizing a callback function:


//This GlideAjax Function retrieves related records from a Script Include for reference on the clientside
var ga = new GlideAjax('RelatedRecords');
//the sysparm_name parameter calls out the function that will be evoked in the script include
ga.addParam('sysparm_name', 'getRecords')
ga.addParam('sysparm_foreign_id', g_form.getUniqueValue());

function RecordsParse(response) {
   //In this case we are going to assume that the script include is returning an array of records
   var answer = response;


These are some examples of how we can reduce the dependencies of process execution in the system and attempt to avoid poor performance. We focused mostly on asynchronous data processing and code execution. These practices can reduce the appearance of performance issues to users and take advantage of the system’s resources efficiently. Applications that do not create long running processes will not interfere with other users and applications in the system. Having this environment where applications interact but do not collide will encourage people to use the platform. In a future article where we discuss some basic optimizations and strategies for tables and the data stored there to improve querying efficiency and reporting.

Dot-walking got its descriptive name because, when dot-walking, you reference a field by building a chain of field names separated by dots. For example, incident.change_request.state references the state of the change request associated with an incident. Dot-walking is commonly used when personalizing forms, so I'll discuss the two together in this post.


Dot-walking is one of my favorite ServiceNow terms




If you are using ServiceNow, chances are you have right-clicked a form header and selected Personalize > Form Layout (beginning with the Fuji release, you'll select Configure > Form Layout). This magical feature enables administrators and users with the personalize_form role to customize a form. The base system Incident form not working for you? Configure it. Use the slushbucket to move fields on and off the form and arrange them. For example, select the Business Duration field in the Available list and click the Add button to move the field to the Selected list.




In the slushbucket, notice that some of the entires in the Available list are displayed in green and have a plus sign next to them. These entries represent related tables. Click the plus sign to dot-walk and access all the fields on the related table. For example, click Change Request [+] and then click the green plus sign above Add.




The Available list now shows the Change Request fields:




Select any field in the Available list and click Add to add the field to the Incident form. This enables you to, for example, more closely track change requests created from incidents. Note that the next time you open the slushbucket, the Change Request fields are not expanded and shown in the Available list - to view them again you need to click the plus sign again. To list the fields on the Incident form again, click Incident fields at the top of the Available list.


Tips for dot-walking


The dot-walking possibilities are endless when you are personalizing forms. Here are some tips.

  • Users frequently ask about the gear feature as compared to the Personalize List feature. They are different. When a user clicks the gear icon, the slushbucket only lists fields on the current table. With the Personalize List feature, the slushbucket lists related tables and allows you to dot-walk to them. Also, if you make changes using the gear, the changes are visible only to you, but if you personalize a form, the changes are seen by all users with access to the form and view.
  • In order to dot-walk, you must have read access to the target table and field. It is a good idea for administrators to impersonate an intended user and check that the user can access the target fields.
  • In the community, Jessica Luerkens asked if it was possible to dot-walk to related fields when creating a personal list.Mark Stanger came through with the correct answer - unfortunately, it is not possible at this time.
  • If you use UI policies, it is critical that any condition fields are visible on the form. Personalize the form, dot-walking if necessary, to add the fields. maja jovanovic wrote a great blog post about this issue just last month. 
  • In addition to forms, you can dot-walk in field drop-downs, list collectors, variables, a tree picker, and in script. For more information see Dot-Walking in the product documentation.

"I think the most important thing is to keep active and to hope that your mind stays active."

-Jane Goodall


If you use tasks, consider setting up an inactivity monitor to help prevent the work from being forgotten. Inactivity monitors trigger an event for a task if the task has not been updated in a predefined period of time. For example, the event can send an email notification or trigger a script. If the task continues to be inactive, the monitor keeps triggering the event. Tasks are commonly used on incidents, problems, changes, projects, and SDLC sprints.


Creating an inactivity monitor with an email notification

  1. Navigate to System Policy > SLA > Inactivity Monitors.
  2. Click New.
  3. Type a Name. For example, Priority One Inactivity.
  4. Select the task type to monitor in the Table field. For example, Incident.
  5. In Wait, specify the time in hours and/or minutes to wait before sending notification. For example, 2 hours.
  6. In Condition, at least one condition must be specified. You can set multiple conditions. For example, on a priority one incident inactivity monitor, the conditions could be:
  7. Click Save.

    Note: The Order field on the Inactivity Monitor record is optional, but can be important. If more than one inactivity monitor could have their conditions met for a specific record, the monitor with the lowest Order number is used. As you create more inactivity monitors, double-check existing inactivity monitors and their conditions to identify the monitors that are related and could apply to the same record.

  8. Now, you need to set up an event for the inactivity monitor. We want to create an email notification, so navigate to System Policy > Email > Notifications.
  9. Type a Name. For example, Priority One Inactivity.
  10. Select the correct Table. In this example we would use Incident [incident].
  11. Under Related Links, click Advanced view.
  12. In Type, select EMAIL.
  13. In Send when, select Event is fired.
  14. In Event name, select incident.inactivity.
    If necessary, you can create a new event and register the event.
  15. Click Update.

Tips for using inactivity monitors

  • Inactivity monitors only apply to records on the Task table or tables (such as Incident or Problem) that extend the Task table.
  • Updates to the task record restart the monitor. However, if the monitor has reset conditions defined, but the conditions are not met when the task record is updated, the monitor is not restarted.
  • When the conditions for an inactivity monitor are met, an event is generated in the form <tablename>.inactivity. No actions take place, however, unless an email notification or script action is defined.
  • There is a nifty way to close incidents automatically, but if you want to use this method and you have an inactivity monitor on your incidents, you'll need to put a reset condition on your inactivity monitor. For more information, see Closing Resolved Incidents Automatically in the product documentation.
  • Inactivity monitors are different from service level agreements (SLAs). An SLA checks that a task reaches a specific condition in a specific amount of time. For example, SLAs are commonly used to ensure that an incident is resolved within a certain amount of time. A key difference between inactivity monitors and SLAs is that SLAs are workflow driven, so they are very flexible and can be customized. For more information about SLAs, see Service Level Agreements in the product documentation.
  • In the task history, inactivity monitors against a specific task show as updated by “System." This can be confusing when reviewing the task history.


ServiceNow offers more information about inactivity monitors in the product documentation:

System Performance Best Practices - Removing Unused Inactivity Monitors

Events and Email Notification

Introduction to Tasks

Filter Blog

By date: By tag: