Handling Simultaneous Updates in ServiceNow

//Handling Simultaneous Updates in ServiceNow

Handling Simultaneous Updates in ServiceNow

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

Usage:

This customization is only offered as an update set through ServiceNowGuru.com. 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:

By | 2018-07-09T15:00:02+00:00 January 12th, 2011|Categories: System Definition|Tags: , , , , |70 Comments

About the Author:

Mark has worked in the IT industry since 2002 and with ServiceNow since 2007. He is the founder and creator of SN | Guru and the co-founder of Crossfuze, one of the worlds leading ServiceNow consulting partners. Prior to co-founding Crossfuze, he worked for ServiceNow as a Senior Architect on the Professional Services team. He has personally led dozens of successful implementations encompassing every part of the ServiceNow platform. He is also responsible for designing and developing groundbreaking ServiceNow solutions and best practices in the form of various applications, turnkey solutions, and integrations during his tenure at ServiceNow, Crossfuze and, of course, SN | Guru. These solutions are used today by ServiceNow administrators and consultants alike in hundreds of ServiceNow instances around the world!

70 Comments

  1. Brad Hicks January 12, 2011 at 3:57 am - Reply

    Awesome!!!

  2. Matt Gaide January 12, 2011 at 11:08 am - Reply

    Very cool!

  3. Shirley Cote June 2, 2011 at 8:48 am - Reply

    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

    • Mark Stanger June 2, 2011 at 11:33 am - Reply

      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.

  4. BJ July 6, 2011 at 8:50 am - Reply

    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.

    • Mark Stanger July 6, 2011 at 9:04 am - Reply

      @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.

      • BJ July 7, 2011 at 3:04 am - Reply

        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

        • Mark Stanger July 7, 2011 at 8:38 am - Reply

          @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.

          • BJ July 7, 2011 at 5:31 pm - Reply

            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

  5. Mark Stanger July 7, 2011 at 10:17 pm - Reply

    @BJ There aren’t any performance issues or overhead that I’m aware of.

  6. Joe August 9, 2011 at 8:15 pm - Reply

    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

    • Mark Stanger August 9, 2011 at 9:19 pm - Reply

      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()’.

  7. MilkMan November 22, 2011 at 5:45 am - Reply

    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.

    • Mark Stanger November 22, 2011 at 8:09 am - Reply

      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.

      • Divya December 5, 2011 at 11:28 pm - Reply

        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

        • Misabi December 5, 2011 at 11:58 pm - Reply

          We just noticed the same issue today.

          • Mguillory June 14, 2012 at 7:59 am - Reply

            I have just been informed that some of our users are experiencing the same issue.

        • Mark Stanger December 6, 2011 at 5:34 am - Reply

          @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?

          • Mguillory June 14, 2012 at 8:29 am - Reply

            FYI, I implemented this at the end of May 2012 and we are running Aspen 1-16-2012_1438

        • Andrew August 20, 2012 at 1:31 pm - Reply

          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.

  8. Misabi December 6, 2011 at 5:45 pm - Reply

    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

    • Mark Stanger December 6, 2011 at 5:55 pm - Reply

      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.

  9. Jaakko Jalo December 15, 2011 at 5:13 am - Reply

    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?

    • Mark Stanger December 15, 2011 at 10:07 am - Reply

      Unfortunately both of those are system generated so I’m not even sure that they can be changed.

    • Andreas December 13, 2012 at 2:33 pm - Reply

      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.

      • Zach Kenyon April 7, 2014 at 9:26 am - Reply

        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”);

        • Mark Stanger April 7, 2014 at 9:37 am - Reply

          Thanks for the feedback! I’ve updated the code in the update set with this fix.

  10. Jaakko Jalo December 21, 2011 at 2:50 am - Reply

    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.

    • Jaakko Jalo December 21, 2011 at 2:56 am - Reply

      Nevermind about the new window not having alerts, my bad.
      But still a way to make it read-only. Is it possible?

      • Mark Stanger December 21, 2011 at 7:03 am - Reply

        I’m not sure what you’re talking about. The popup is completely read only for simultaneous updates.

        • Jaakko Jalo December 21, 2011 at 11:10 pm - Reply

          “Click here to view the previously-saved record in a new window.”
          This new window is what I meant.

          • Mark Stanger December 21, 2011 at 11:14 pm - Reply

            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.

  11. Brian Arndt December 21, 2011 at 7:14 am - Reply

    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?

    • Mark Stanger December 21, 2011 at 8:58 am - Reply

      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.

      • Brian Arndt December 22, 2011 at 6:11 am - Reply

        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.

        • Joe Dziedzic February 28, 2013 at 9:03 pm - Reply

          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.

          • Mark Stanger March 1, 2013 at 6:12 am - Reply

            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!

  12. Carlito de Jesus December 13, 2012 at 4:52 pm - Reply

    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?

    • Mark Stanger December 13, 2012 at 8:45 pm - Reply

      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.

  13. Liam December 28, 2012 at 10:24 am - Reply

    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.

    • Mark Stanger December 28, 2012 at 10:32 am - Reply

      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.

      • Liam December 28, 2012 at 2:31 pm - Reply

        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

        • Mark Stanger December 29, 2012 at 6:54 am - Reply

          I don’t see any obvious issues, but please let me know if you experience any problems as you use it.

          • Shakti April 12, 2013 at 5:10 am - Reply

            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.

            • Mark Stanger April 12, 2013 at 6:23 am

              I believe the latest update set already has a fix similar to this. Is it not working for you?

          • Shakti April 12, 2013 at 6:36 am - Reply

            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//

  14. Howard Elton January 2, 2013 at 1:07 am - Reply

    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 🙂

    • Andreas January 9, 2013 at 9:45 am - Reply

      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.

  15. Anurag January 31, 2013 at 12:12 am - Reply

    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.

    • Mark Stanger January 31, 2013 at 6:32 am - Reply

      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.

      • Anurag January 31, 2013 at 9:31 am - Reply

        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).

  16. Rob April 16, 2013 at 5:46 am - Reply

    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?

    • Mark Stanger April 17, 2013 at 6:43 am - Reply

      Hard to say for sure, but it might be due to some unescaped ampersands in the names of your CIs or some other record.

      • Cosmin June 28, 2013 at 7:34 am - Reply

        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

        • Cosmin June 28, 2013 at 8:19 am - Reply

          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’);

          • Cosmin June 28, 2013 at 9:24 am - Reply

            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()}’);

            • Mark Stanger June 28, 2013 at 10:26 am

              Perfect! Thanks for the fix. I’ve incorporated it into the download code here on SNGuru.

  17. Cosmin June 28, 2013 at 10:46 am - Reply

    Mark – thank YOU for making this wonderful solution publicly available and putting the fix in so quickly!

    • Cosmin July 1, 2013 at 8:52 am - Reply

      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

      • Cosmin July 1, 2013 at 1:10 pm - Reply

        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.

        • Andreas July 18, 2013 at 12:41 pm - Reply

          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.

  18. John August 6, 2013 at 10:58 am - Reply

    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

  19. Lionel April 29, 2015 at 3:34 am - Reply

    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

  20. jugi July 31, 2015 at 12:24 am - Reply

    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?

    • Mark Stanger July 31, 2015 at 6:35 am - Reply

      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.

  21. Gareth September 22, 2015 at 5:07 pm - Reply

    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?

    • Mark Stanger September 22, 2015 at 5:12 pm - Reply

      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.

  22. Rob January 12, 2016 at 4:06 pm - Reply

    So this will work on Fuji P8?

  23. Prathima July 13, 2017 at 12:04 pm - Reply

    Hi Mark,

    Can I use this update sets for Helsinki version??

    • Jim Pisello July 14, 2017 at 9:59 am - Reply

      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.

Leave A Comment