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.
Old Simultaneous Update Alert

SNCGuru 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:
- ‘Simultaneous Update Alert (Listener)’ client script on the ‘Task’ table:
- ‘Get Simultaneous Update Properties’ business rule on the ‘Task’ table:
- ‘SimultaneousUpdateAlert’ script include:
- ‘simultaneous_update_alert’ UI page:
- ‘simultaneousalert.enabled’ system property:
- ‘simultaneousalert.listen.interval’ system property:
Triggers the check for updates onSubmit of any ‘Task’ record.
Triggers the check for updates every ‘X’ number of seconds as indicated in the ‘simultaneousalert.listen.interval’ system property.
‘Display’ business rule that sets system property values for use in client scripts.
Back-end piece to AJAX query. Returns the last updated date of a record to client scripts.
Alert page that displays message, option buttons, and activity for an updated record.
Controls whether the functionality runs onSubmit, as a Listener, both, or not at all
Controls the listen interval for listener modes
Usage:
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.
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.
Related Links:
- Download: Simultaneous Update Alert
- Supporting Documentation: Installing an update set on your instance
Awesome!!!
Very cool!
This exactly what we were looking for but I would like to make a few changes. What program did you use to write this and do you mind that I change it reshare or would it be best to ask for you help.
With my company we would like to remove the OK button and a few more cosmetic changes.
I love the pop up!
Thoughtssssssssssssss/
Thanks,
Shirley
You’re free to modify it however you need. I just used a standard text editor to write the code for it. If you want to modify the popup you’ll need to edit the ‘simultaneous_update_alert’ UI page. Fair warning: it’s fairly complex code so you’ll need to be comfortable with scripting if you are going to make modifications on your own.
Mark you are a legend!
Although what if I just wanted to know on page load that someone else has the record open (eg through a popup message)?
This way I could decide to just view the page without making any changes.
@BJ This is a pretty common request and I’ve actually tried to think through some ways that something like this could be implemented. The problem is that it’s extremely difficult to tell when someone is no longer viewing a record. You could easily set up a script to flag that the record is being viewed, but how do you identify when the record is no longer being viewed by that same user when they can navigate away, close the window or browser completely…but still have a separate browser open with the same record displayed, leave for the weekend with their browser open to a particular incident, or have their session time out? That’s the challenge, and I’m not sure of a good solution to it unfortunately.
I think the ‘Listener’ piece of this functionality comes pretty close to your goal though because it notifies you almost instantly of any updates made to the record. You don’t have to trigger a form submission to be notified and there’s no mess of trying to determine when a record isn’t being viewed anymore. You can open a new window from the popup to view the newly-saved information if needed.
Hi Mark,
yeah that sounds reasonable.
I’ve installed on my test instance and don’t see the activity section (showing fields that have changed). I have the latest release of Service-now.
Cheers,
BJ
@BJ I’m seeing the same issue on the ServiceNow demo instance but it isn’t happening on 2 separate instances that I have running the latest build. I’m having a hard time tracking down anything that would cause the activity section not to appear. Let me know if you find anything.
No problem – I’ll look out for it.
On a side note – does the listener functionality result in any performance overheads? eg excessive memory use over time, CPU use etc?
Cheers,
BJ
@BJ There aren’t any performance issues or overhead that I’m aware of.
This looks great, much better than the previous version 🙂
One thing, some of our customers have found it confusing in testing as they don’t see the updates made to the work notes and other fields. So while they get a message saying that someone else has updated the record since they opened it, when they look at the record they don’t see the changes.
Can we stop the customers from seeing the popup? e.g. restrict it to those with the itil role only
Thanks in advance,
Joe
Sure. You can customize the client scripts to do this. Simply wrap the client script code inside an ‘if’ statement and check for a role using ‘g_user.hasRoles()’.
This is ridiculously too complicated… and wile a great improvement on the orriginal update script, it still doesn’t solve the problem of someone else opening the ticket at the same time and work getting duplicatd. All that needs to be done (what others and myself are trying to implement) is a time stamp at the top that says Last Opened by Blank, x minutes x seconds ago, and that time goes away after say 10 or 20 minutes. You don’t need to track if the person is still there or left the window open etc. It just lets you know someone else is looking at the ticket and if you need to you can talk to that person to see if they are working it etc.
Other helpdesk systems include similar features out of the box, amazed that service now does not.
I’m not sure how this idea is going to solve that problem either…or be any less complicated than what I’ve built. You’re still going to need some client scripts and a Script Include at a minimum. I’d love to hear about any solution you come up with, but in the end you’re still guessing about whether somebody is really in the ticket working on it or not. At least with this solution you know for sure that an action has been performed…as it is performed. Anything else would just cause more confusion in my opinion.
Mark,
We are now getting a new Simultaneous Update Alert in Incidents and are not able to get out of the alert.
The pop up notification advises
Simultaneous Update Alert
The entity name must immediately follow the
‘&’ in the entity reference
There are no action buttons, no exit button etc. and no ‘X’ in order to close the alert and the incident is grayed out in the background and not available (see attached screenshot). The only way to get out of this is to use the browser back arrow or close the browser
We just noticed the same issue today.
I have just been informed that some of our users are experiencing the same issue.
@Divya and Misabi…What ServiceNow release are you on? Did you just upgrade? Have you checked to make sure you’re running the latest simultaneous update code?
FYI, I implemented this at the end of May 2012 and we are running Aspen 1-16-2012_1438
It is a escaping issue.
All newer instances (not sure since when, maybe everything created after June 2011?) have a property “glide.ui.escape_text” that escapes at the parser level. Setting that property to “true” can be used as a workaround.
I’m not sure what in the code is not escaped correctly, and this causing the error, but setting the problem should fix the issue until someone can figure out where the escaping issue resides.
Plus having “glide.ui.escape_text” set to “true” is a good idea for security anyway, it prevents scripting attacks.
Hi Mark,
We only implemented the new simultaneous update alert script in November, using your update set that we downloaded in Sept this year.
Our instance shows the version as: 5.0.51a-log
We last upgraded to the June 11 update a few months ago, but I believe that we have had some patches installed since then to fix various bugs.
Thanks
You might try removing specific sections of the UI page to see if any particular section is causing an issue. Without having access to your instance it’s hard to say what might be going on. I did a fresh install of the update set on one of the demo instances this morning and it seemed to work just fine there. If you can reproduce the same issue on demo then I can take a closer look there but I’m not seeing any issues on the instances I have access to.
Works wonderfully after I figured out that the date format in g_user_date_time_format did not match the one actually used in the strings. Had to hardcode the correct format into the client scripts.
Where is ‘Load_sys_updated_on’ set?
Not sure about changing the g_user_date_time_format in UI Properties either in case it breaks something else. How far and wide is the latter variable used in general?
Unfortunately both of those are system generated so I’m not even sure that they can be changed.
Hi Jaakko,
can you share your modification of the client script? It seems like I have the same issue here and we have a custom date and time format configured in our system properties.
Much appreciated,
Andreas
PS: We’re running Berlin Patch 2 Hotfix 2 in case there is something in the latest version/patches which breaks the functionality of this awesome solution.
It looks to me like the date/time stored in $(‘onLoad_sys_updated_on’).value and in the sys_updated_on field on the record use the date/time format of “yyyy-MM-dd HH:mm:ss” no matter what date/time format is set on the system or for the user.
The fix that worked for me was to replace g_user_date_time_format with “yyyy-MM-dd HH:mm:ss” on lines 37 & 38 of the client script:
var lastAlertDt = getDateFromFormat(lastAlert, “yyyy-MM-dd HH:mm:ss”);
var dbUpdatedOnDt = getDateFromFormat(dbUpdatedOn, “yyyy-MM-dd HH:mm:ss”);
Thanks for the feedback! I’ve updated the code in the update set with this fix.
Another thing: Is it possible to make the window (the one you open to view the changes made by that other person) read-only? If nothing else than at least a way to disable save/update/etc from it.
As the ticket opened in the new window can be edited freely and saved without any alerts popping up.
Nevermind about the new window not having alerts, my bad.
But still a way to make it read-only. Is it possible?
I’m not sure what you’re talking about. The popup is completely read only for simultaneous updates.
“Click here to view the previously-saved record in a new window.”
This new window is what I meant.
I don’t know of a simple way to do that off-hand, but I’m not sure why that would even be a concern. You’ve got write access to the record since you’re working on it anyway. The popup would just use the same security you’re already using.
Mark, first I want to thank you for offering this as a downloadable update set. We just implemented it in our instances. I think it’s an elegant solution to something that I’m surprised isn’t handled better OOB. Have you experienced the alert sometimes being triggered when a user adds an attachment despite no other users being in the record at the same time? Any thoughts about what might cause that?
Thanks! I haven’t noticed the issue you describe but you might want to check the update set to make sure that the version you have was applied after 9-9-2011. That’s the last time I updated the update set. If you can manage to find a way to reproduce the issue consistently I can take a closer look.
It was just about a month ago that I downloaded it, so I’m sure it was the 9-9-2011 version. I just applied it to the demo site this morning but I can’t reproduce it there. I can however reproduce it consistently every time the first attachment is added to a task in our environments (we’re on the June release). Of course you can’t investigate it there, but if you have any ideas, I’d love to hear them.
We are experiencing the same issue as well. It appears to be conflicting with the following script that adds an entry to the activity filter when an attachment is added or removed.
http://community.servicenow.com/blog/mb/attachment-loggingauditing-where-did-attachment-go
Even though you are adding the attachment, the Simultaneous Update Alert doesn’t know it was you that added the attachment, so it just thinks that someone else did. I’ve disabled the attachment logging, and I dont see the error anymore. Is there a way for the attachment logger to refresh the activity filter, or maybe have the update alert not check changes made to the activity filter? I’ve taken a look at the 2nd option, but I did not have success.
Thanks for pointing this out! The simultaneous update alert code doesn’t check to see whether or not the last update is made by the current user or not. That’s why you’re seeing the alert in this case. I think there are cases where that might be useful, but probably not very many. I’ve just changed the behavior of the alert to only pop up if the update was made by a different user. You can download the new update set and apply to your instance to get the changes. Please let me know how it works!
Hi Mark,
This looks really cool! However, doesn’t seem to work on our Instance. The option to configure in UI Properties is not there.
I have checked all of the Core Components after I uploaded the update set and they are all present. We are currently on Aspen release.
Any suggestions?
I’m not sure what might be happening. I just installed it without issue. You might need to re-apply the update set. You can look at the ‘sys_properties’ table to see if the ‘simultaneousalert’ properties exist there.
I have installed this update set in our DEV environment, but when I try to test it (two different browsers, impersonating two different people) I never get any alerts, and any updates I make overwrite previous updates.
I’ve confirmed this works correctly by testing it on a ServiceNow demo instance. The best thing I can suggest is to try on a SN demo instance and see how it works there. Without direct access to your instance I’m afraid there’s not much I can do to help other than to tell you to compare to a working installation. Bad client scripts or UI policies in your instance might cause this to break so you should check for browser errors in your browser console as well.
Well, with a little tweaking of the client scripts I believe I have gotten it to work!
First off, for some reason, in both the submit and listener scripts, our DEV instance did not like these lines:
var lastAlertDt = lastAlert //getDateFromFormat(lastAlert, g_user_date_time_format);
var dbUpdatedOnDt = dbUpdatedOn //getDateFromFormat(dbUpdatedOn, g_user_date_time_format);
so I just set the xxxDt vars to the unformatted value (I was getting 0 and 0 for the values when I left the formatting in there) and it works as expected (and as it does in the demo version I installed it on).
Next, in the listener code this line was not returning any data: var lastAlert = gel(‘lastAlert’);
So I mimicked the code from the submit script and it seems to be working now:
var lastAlertNode = gel(‘lastAlert’);
var updatedOn = gel(‘on’ + ‘Load_sys_updated_on’).value;
var lastAlert = ”;
if(lastAlertNode){
lastAlert = lastAlert.value;
}
if(!lastAlert || lastAlert == ”){
lastAlert = updatedOn;
}
I’m not sure why our system was not able to get those date values, but it is working now.
Any red flags you see with these changes?
Thank you,
Liam
I don’t see any obvious issues, but please let me know if you experience any problems as you use it.
Hi Liam,
I was looking at the fix you tried which works fine for you. Was looking for some assistance since I am very new to scripting.
first: how to set the xxxDt vars to the unformatted value in the submit script?
second: I cant find the part of the script in listner that you refered to “var lastAlert = gel(‘lastAlert’);” which you changed.
Could you please point me to were this is. I am working using the latest update set available to download in this post from Mark.
I believe the latest update set already has a fix similar to this. Is it not working for you?
No it didnt work, when second user tries to save his change the ui popup is a standard one stating the record has been updated by user (xxx) since you opened it – overwrite those changes with your? …etc//
I couldn’t get this to work either, although I did not pursue it as thoroughly as Liam did. I am using Berlin and have Australian date-time format. I mention this because this is an obvious difference in formats which is something I am yet to look into. I wonder what DT format others, who experienced problems, are in. I will revisit it when my change request list gets below 20 🙂
I did some testing and basically it comes down to the configured date format itself. We changed our date format to use a “/” instead of a “-” as a delimiter between year, month and day. When we changed this back to a “-” everything works just fine.
Hi Mark,
Is it possible to have this type of Alert on KB view UI page while some end user is providing his feedback on knowledge base article and in the back end this article is getting edited by some technician.
It’s possible, but it would be quite a bit different. Instead of comparing the dates on the record itself, you would need to compare the count of feedback records from when the article was opened. I don’t have a way currently to do that, but you could probably modify this solution to work that way.
Hi Mark,
Can you please elaborate a little bit more about how feedback count has to be changed in which script(client script/business rule).
Hi Mark,
This is just what we were looking for, but we are getting errors from time to time stating:
“Element or attribute do not match. QName production: QName::=(NCName’:’)?NCName.”
or
“The entity name must immediately follow the ‘&’ in the entity reference.”
Any ideas where these errors could be coming from?
Hard to say for sure, but it might be due to some unescaped ampersands in the names of your CIs or some other record.
Hi Mark,
Thank you very much for this nice solution. This solution really helps us here at U of Minnesota. Very frequently we have folks here working on the same tickets so this solution is greatly appreciated.
I am able to reproduce this error consistently both on our instances (Berlin Patch 7) and demosandbox (Calgary). The only thing I need do is use the ampersand in an update to an INC ticket (e.g. bonnie & clyde) — getting “The entity name must immediately follow the ‘&’ in the entity reference.” (I loaded your March 1st update set). Which piece do we need to tweak in order to avoid this error?
Thanks in advance!
Cosmin
OK… I think I got it figured out. On the UI Page “simultaneous_update_alert” I added a line under the section that replaces the html code tags, in order to replace the ampersand with the ‘and’ word (lines 145-153)
if (typeof GlideStringUtil != ‘undefined’)
var histNew = new GlideStringUtil().unEscapeHTML(‘${JS:history.new.getDisplayValue()}’);
else
var histNew = Packages.com.glide.util.StringUtil().unEscapeHTML(‘${JS:history.new.getDisplayValue()}’);
histNew = histNew.replace(‘[code]’, ”);
histNew = histNew.replace(‘[/code]’, ”);
histNew = histNew.replace(‘${AMP}’, ‘and’);
even a better version that actually renders the ampersand properly instead of replacing it w/ ‘and’ and accounts for the situation when HTML [code] tags are allowed (glide.ui.security.allow_codetag = true)
if (typeof GlideStringUtil != ‘undefined’)
var histNew = new GlideStringUtil().unEscapeHTML(‘${JS:history.new.getDisplayValue()}’);
else
var histNew = Packages.com.glide.util.StringUtil().unEscapeHTML(‘${JS:history.new.getDisplayValue()}’);
histNew = histNew.replace(‘[code]’, ”);
histNew = histNew.replace(‘[/code]’, ”);
histNew = histNew.replace(‘${AMP}’, ‘$[AMP]’);
if (typeof GlideStringUtil != ‘undefined’)
var histNew = new GlideStringUtil().unEscapeHTML(‘${JS:history.new.getHTMLValue()}’);
else
var histNew = Packages.com.glide.util.StringUtil().unEscapeHTML(‘${JS:history.new.getHTMLValue()}’);
Perfect! Thanks for the fix. I’ve incorporated it into the download code here on SNGuru.
Mark – thank YOU for making this wonderful solution publicly available and putting the fix in so quickly!
Hi Mark,
Sorry to bug you again. It seems like the code I pasted in on my previous comment missed this additional line I included for the situation when HTML [code] tags are allowed (glide.ui.security.allow_codetag = true)
if (typeof GlideStringUtil != ‘undefined’)
var histNew = new GlideStringUtil().unEscapeHTML(‘${JS:history.new.getHTMLValue()}’);
else
var histNew = Packages.com.glide.util.StringUtil().unEscapeHTML(‘${JS:history.new.getHTMLValue()}’);
histNew = histNew.replace(‘${AMP}’, ‘$[AMP]’);
When you get a chance, please include it on your latest release of ‘Simultaneous Updates in Service-now’ feature.
Thanks and have a great day!
Cosmin
Looks like other situations may occur with other characters that need escaping such as . Instead of replacing all of them I tried replacing the unEscapeHTML() function with getHTMLValue() function. This seems to work fine for me.
We also have an interesting effect: instead of the typical content, the pop-up window rather displays an error message:
‘Element type “mailto:helpdesk” must be followed by either attribute specifications, “>” or “/>”.’
This seems to be the result if a user answered an email sent by the instance using their email client which does not perform proper HTML re-formatting.
Mark,
This is an awesome solution, but it’s giving our ITIL Mgrs fits. There are too many options for them. Is there a way to replace the javascript:popupOpenStandard() with a popupOpenFocus() function? We would like to be able to keep the updated window open, and allow the user to copy and paste their comments into the updated ticket.
Thanks,
John
Thanks a lot, just implemented it on our DEV environnement.
Works perfectly after importing the upodate set
env : glide-eureka-04-08-2014__patch7-11-05-2014
Hi Mark,
thanks, your solution is really nice and helpful.
Is it possible to modify the message in the notification popup when email was sent by another agent. Now the message box says that incident was updated, but does not show that update was done by sending an email.
Perhaps its possible to show the update type and content of the email that was sent?
It’s possible, the code is completely open for you to modify the UI page. The real problem you’ll need to overcome is the fact that the system doesn’t track whether the last update to a ticket occurred via an email update or not. So you would also need to put a business rule/inbound email action and a new field in place to track that first. Once you did that, you could modify this solution to add information from that new field.
Hi Mark,
We are on Fuji Patch 8 and have had this functionality for a while.
Since we upgraded to patch 8 the pop alert box is translucent and hard to read with the form in the background. Is there a way to fix that?
I haven’t seen this particular issue, but you should be able to modify the background color within the HTML code in the UI page to whatever you want.
So this will work on Fuji P8?
Hi Mark,
Can I use this update sets for Helsinki version??
Hi Prathima,
We haven’t tested the update set against a Helsinki instance specifically, although it should work.
As always, we recommend that you add the code to a sub-production instance and thoroughly test it before using it in production.