It’s not uncommon in any application to have scenarios where multiple people might be working with a single record at the same time. This is certainly true with ServiceNow (particularly for records on Task tables). You may have experienced frustration while working with an incident record, making updates, and having some of those updates overwritten a few minutes later because somebody else had the record open at the same time and didn’t know about the changes you had made. Because of situations like this, there is often a need to provide some sort of record lock or alert capability that lets people know when other people are working with the same record.

In the past, you may have used the ‘Simultaneous Update Alert’ script from the ServiceNow wiki to provide this capability. While that solution works fine, and I’ve used it on almost every engagement I’ve been involved with since it became available, it’s pretty limited in the information it provides back to the end user. You just get a simple alert on record submission…no details, no available actions other than to go ahead and submit or cancel, etc.

I recently had a coworker recommend the use of a UI page to provide a little more flexibility to the messaging that comes with the simultaneous update alert on the wiki. I thought this was a great idea and I had some time over the New Year’s holiday so I started working on it. I’ve finally come up with a solution that I’m happy with and have posted it here in the SNCGuru downloads section as the ‘Simultaneous Update Alert’ update set.

Simultaneous Update Alert

The Simultaneous Update Alert update set utilizes two concepts introduced in the Fall 2010 Stable 2 build…History Sets, and Display business rules. You’ll need to make sure your ServiceNow instance is running the Fall 2010 Stable 2 build or later if you want this to work in your system.

Old Simultaneous Update Alert

Original Simultaneous Update

SNCGuru Simultaneous Update Alert

Simultaneous Update Alert

This customization includes the following features:

  • Simultaneous update alert runs as a listener to alert users as soon as changes are made, onSubmit, or both!
  • Configuration properties to easily enable/disable, and adjust the listener interval
  • UI page-driven alert displays multiple options to proceed, cancel, refresh, or view in a new window
  • Alert displays all user-readable activity (for audited tables) since the record was opened

Core components:

This solution includes the following elements:

  • ‘Simultaneous Update Alert (Submit)’ client script on the ‘Task’ table:
  • Triggers the check for updates onSubmit of any ‘Task’ record.

  • ‘Simultaneous Update Alert (Listener)’ client script on the ‘Task’ table:
  • Triggers the check for updates every ‘X’ number of seconds as indicated in the ‘simultaneousalert.listen.interval’ system property.

  • ‘Get Simultaneous Update Properties’ business rule on the ‘Task’ table:
  • ‘Display’ business rule that sets system property values for use in client scripts.

  • ‘SimultaneousUpdateAlert’ script include:
  • Back-end piece to AJAX query. Returns the last updated date of a record to client scripts.

  • ‘simultaneous_update_alert’ UI page:
  • Alert page that displays message, option buttons, and activity for an updated record.

  • ‘simultaneousalert.enabled’ system property:
  • Controls whether the functionality runs onSubmit, as a Listener, both, or not at all

  • ‘simultaneousalert.listen.interval’ system property:
  • Controls the listen interval for listener modes


This customization is only offered as an update set through You’ll need to install an update set into your instance to get this functionality. Installation and download instructions can be found below.

I’ve tried to keep this solution as simple as possible to use, even though there’s a lot of complexity in the scripts themselves. You’ll notice in the ‘Core components’ section above that the ‘Simultaneous Update Alert’ client scripts and the ‘Get Simultaneous Update Properties’ business rule are set up for the ‘Task’ table only. These scripts control what tables the functionality will be available on. I decided to only set it up on task tables by default since that is the most common usage. The most common configuration modification (other than the system properties) will probably be to add the functionality to other tables. To do this, simply copy all three of these scripts to the new table(s) and it should work there as well.

While it’s possible to add this to other tables in your system, don’t overdo it!!! The scripts are designed to have a minimal impact on your system, but overuse may result in poor system performance. Only use this where it is absolutely necessary!

Standard configuration properties for enabling/disabling and setting the listen interval can be found under the ‘System Properties’ application, ‘UI Properties’ module as shown in this screenshot.
Simultneous Update Alert Properties

Related Links: