Hello SNUG Members!   We had over 1,400 people from all over the world join us for the 2025 Holiday SNUG event this year.   A HUGE thanks to our presenters from Bristol Myers Sqibb, UNC Health, and KeyBank as well as our superstar ServiceNow Solution Consultant Travis Rogers and my AMAZING cohost developer advocate Lauren McManamon!   You can find the recording of the event as well as the customer presentations HERE.     I hope you are able to attend Knowledge 2026 – early registration is open!   Wishing all of you a healthy, happy holiday season!   Tracy O’Brien ... View more

Hello SNUG Members!    It's not too late to register for the upcoming 5th annual virtual Holiday SNUG event on Tuesday, December 16 th !    We will have a NEW Platform AI workshop to start, customer presentations, and a fun, entertaining magic/mentalist act to finish.    REGISTER TODAY  *You must register in advance to receive Zoom login information. ** If you don't receive your login information, please check your spam/junk email folder(s).    Registered attendees will be provided a link to attend prior to the event with Zoom login credentials. You might be asked to login and/or register for Zoom to enter the virtual meeting.    REGISTER TODAY   * The virtual event will be delivered via Zoom Webinar. Use these links to access information about Zoom Webinar Language and Accessibility features.    Tracy O'Brien SNUG Program Manager ... View more

You are invited to attend the upcoming 5th annual virtual Holiday SNUG event on Tuesday, December 16 th !    Join me and developer evangelist extraordinaire Lauren McManamon hear from amazing customer presenters and be entertained by an AMAZING mentalist -magician you don’t want to miss! Share your reactions and chat with ServiceNow customers, developers, and partners from across the globe.   Forward the registration to friends and collogues- ALL ARE WELCOME. This is the biggest SNUG of the year- you won’t want to miss it.   REGISTER TODAY  *You must register in advance to receive Zoom login information   Agenda 8:00 am - 9:30 am PT Platform AI Workshop   9:00 am - 9:15 am PT Break   9:15 am - 10:00 am PT Welcome – Tracy O’Brien and Lauren McManamon   10:00 am - 10:30 am PT Now Assist Virtual Agent Adoption & Integrations Ken Bristol, Bristol Meyers Squibb   10:30 am - 11:00 am PT How herding cats helped consolidation efforts at AFRL Tauf Chowdhury, AFRL (Airforce Research Laboratory)   11:00 am - 11:30 am PT Identity and Access Management into ServiceNow Christopher Smith, UNC Health   11:30 am PT - 12:00pm PT KeyBank’s journey with ServiceNow and custom app development with App Engine Adam Stockton, Robert Parry, Seth Nauman-Shamatta, KeyBank   12:00 pm PT - 12:30pm PT Mentalist and Magician Performance Gary Ferrar    12:30 pm PT Closing Remarks     Registered attendees will be provided a link to attend prior to the event with Zoom login credentials. You might be asked to login and/or register for Zoom to enter the virtual meeting.        REGISTER TODAY   * The virtual event will be delivered via Zoom Webinar. Use these links to access information about Zoom Webinar Language and Accessibility features.    Tracy O'Brien SNUG Program ... View more

If you build integrations and haven't used the Connection & Credential Alias configuration, please come out from that rock you've been living under and read on! This article will explain how to use the Connection & Credential Alias and why it is so much better than the legacy equivalents. ... View more

In my previous post on Coding Best Practices, we reviewed some Best Practice tips for scripting in general. The ServiceNow platform allows Administrators to enhance the standard functionality by adding scripting to various system components. These components can be separated into two categories: Client-side and Server-side. Now, we'll review some of the Best Practices for Client-side Scripting in ServiceNow. For reference, Client-side scripts are loaded into a user's Web Browser when a page is loaded. Some of these scripts execute automatically after the form is loaded (e.g. onLoad), while others only execute based on a user interaction (e.g. onChange or onSubmit). These scripts are written in JavaScript and can easily fail if not implemented correctly. If this occurs, the page will most likely not function as intended, resulting in corrupted values and a bad user experience. To avoid this, here are my Best Practice recommendations: Avoid global Client Scripts Client Scripts configured on the Global Table will be loaded on every single table form in the system, regardless of whether any of the code is actually needed. This can seriously impact system performance and therefore should be avoided. Client Scripts should be configured to load/execute on specific tables only. Consideration should also be given to whether the script should be inherited by any extended tables, and which views it should apply to. If functions are needed to be loaded on every form, a UI Script could be created. Avoid using DOM (manipulating elements via the Document Object Model) This is a bold statement I know, but it really is just the tip of an iceberg full of potential issues. So why is DOM manipulation such an issue? Well let's take a simple example. Let's say you want to hide a field element. You could inspect the HTML source and identify which element represents the field. Once you know the id value, you could call a standard JavaScript function called document.getElementById() to return the element as a JavaScript Object. Then, you could dot-walk to its style.display property and update its value ("none" for hide, "block" or "inline" for show etc). This would be perfectly fine if the HTML never changed. However, the HTML in ServiceNow's table forms is maintained by ServiceNow, and could (and likely will) change with future releases. If the id value changed, our scenario would fail. Some DOM calls go further than just targeting a specific element by id and could return elements based on their position in the form. Once again, if this position changes, the code would likely fail. Because of this, ServiceNow recommends avoid using DOM where possible, and if you do need to access one of the out-of-box elements, use the GlideForm (g_form) API instead (e.g. use the getElement() function to return the applicable element as an Object). Because ServiceNow maintain both the HTML structure and the GlideForm API, we can rely on their code to return the correct HTML element each time. Another tip is to always check that an Object was returned by the getElement() or document.getElementById() functions, before proceeding to dot-walk to other properties down the tree. This is important because if the element cannot be found, the value returned will be null. If you attempt to dot-walk and access non-existent properties or functions on a null object, the JavaScript processor will fail and produce an error, and in some cases prevent further processing. This usually causes the page to not function as intended, and creates a poor user experience. Even UI Policies can stop working if a page encounters a JavaScript error during the form load. Use UI Policies instead of Client Scripts Often times, we need to make a field read only, mandatory or hidden. For these cases, it is Best Practice to use UI Policies to perform these actions instead of calling functions from the GlideForm (g_form) API in Client Scripts. UI Policies also have the added advantage of being triggered by multiple conditions (e.g. field value changes), instead of just a single field value change (like an onChange Client Script). Additionally, UI Policies can be executed in a specific order, as well as execute further JavaScript functions if required. Use Asynchronous calls via getReference() or GlideAjax In my earlier post on Client-Server Communication, I discussed examples of using getReference() and GlideAjax to request data from the Server. Both of these examples used Asynchronous AJAX calls because that is the ServiceNow Best Practice. Using Asynchronous AJAX calls (e.g. using Callback functions) will avoid freezing the web browser while the data transfer occurs, and results in a much nicer user experience. Use g_scratchpad to minimise server calls Often, we need to use data in our Client Scripts, which is available on the Server, but not readily available on the Client. If these values are known when the form is loaded, they can be retrieved by a Display Business Rule, and made available to Client Scripts by storing them on a global JavaScript Object called g_scratchpad. Such examples include System Properties or field values from Database records. By first storing them on the g_scratchpad object when the form is loaded, it avoids the need to use an AJAX call to request and receive the required data. Set the Display Value as well as the Value on Reference fields When setting the value of a Reference field via script, we need to use (at minimum) the sys_id value of the record we want to select. When this happens, ServiceNow will automatically make a Synchronous AJAX call to the Server to determine the Display Value for the record we've selected, and then display this value on the form. As per my previous points on Client-Server communication and Asynchronous vs Synchronous AJAX calls, it is Best Practice to avoid Synchronous calls altogether, and to minimise server calls in general. With this in mind, the Best Practice when setting a value into a Reference field is to also set the Display Value at the same time, as this will prevent the additional Synchronous call to the Server. This can be achieved by adding an additional argument to the setValue() function. For example: Never use GlideRecord in Client Scripts Although the GlideRecord Class is available on the Client-side, ServiceNow recommends using GlideAjax instead. First of all, unlike the Server-side equivalent, the Client-side version of the GlideRecord Class will not provide the same functionality (e.g. no dot-walking and associated function calls). Second, whenever the next() or get() functions are called, a Synchronous AJAX call will be made to the Server and this will momentarily freeze the web browser until the data is returned. Using the Client-side GlideRecord Class is actually very similar to using getReference() with no Callback function, and as discussed in my earlier post on Client-Server Communication, the data returned will contain every field value for the selected record. In the case of records with many fields (or large field lengths) this will take longer to return, and could therefore cause performance issues and create a poor user experience. In this article we've covered some of the principles behind Client Script Best Practices in ServiceNow. In my next article, we'll discuss Server Side Scripting Best Practices and how they apply specifically to ServiceNow. For further information on the topics covered in this article, please see the following pages on the ServiceNow Wiki: Coding Best Practices Technical Best Practices GlideAjax GlideForm Client Side GlideRecord W3Schools: JavaScript Introduction W3Schools: AJAX Introduction NOTE: MY POSTINGS REFLECT MY OWN VIEWS AND DO NOT NECESSARILY REPRESENT THE VIEWS OF MY EMPLOYER. ... View more