ServiceNow onChange Script Error: “TypeError: $ is not a function” – Causes and Solutions

Encountering the error “onChange script error: TypeError: $ is not a function” in ServiceNow can be perplexing for developers. This error typically appears when a client-side script (often an onChange client script) tries to use the $ function (commonly associated with jQuery or Prototype) but fails to find it. In a real example, a developer copying an out-of-box script to highlight a VIP requester field saw this exact error message when the script ran. Essentially, ServiceNow is telling us that the $ function isn’t available in the current context.

Why does this happen? Modern versions of ServiceNow (starting with the London release and onward) introduced stricter client-side scripting isolation. In an effort to enforce best practices and security, new client scripts run in a mode where direct access to the DOM and global libraries like jQuery or Prototype is blocked. This means if you try to use $(...) in a client script without adjustments, you’ll get a TypeError because ServiceNow has isolated your script from those global objects. For developers modifying client scripts, this error halts the intended functionality – your onChange logic won’t complete, and any DOM manipulation you attempted (such as highlighting a field or showing an icon) simply won’t occur.

The good news is that this issue is well-understood in the ServiceNow community. In this article, we’ll explain the common causes of the “$ is not a function” error and walk through verified solutions. By understanding why it occurs and how to fix it, you can safely update your ServiceNow client scripts and avoid disruptions to your forms and UI functionality.

Common Causes of the Error

Several factors can lead to the “TypeError: $ is not a function” in ServiceNow. Below are the most common causes:

• Using jQuery/$ in a script that is isolated: ServiceNow client scripts run in an isolated scope by default in newer releases. In this mode, global variables and libraries (like jQuery’s $ or the Prototype $ function) are not accessible. If your script tries to call $(), it won’t find it, resulting in this error. In other words, the platform deliberately does not load jQuery/Prototype in isolated scripts, so $ is undefined.

  
  

• The “Isolate Script” flag is enabled on the client script: Every client-side script record (Client Script, UI Policy script, UI Action script, etc.) has an Isolate Script setting introduced in the London release. When this flag is True (enabled), ServiceNow runs the script in a sandboxed context (strict mode) with no access to the global window object, document, jQuery, or Prototype libraries. If this flag remains enabled (the default for new scripts), any use of $ will throw a TypeError. In our case, an onChange script with Isolate Script = True will not recognize $ at all.

  
  

• DOM manipulation restrictions in newer ServiceNow releases: Beginning with the London release (2018), ServiceNow implemented stricter DOM access rules for client scripts. New or updated client scripts are by default set to isolate mode, which disables direct DOM access and global variables unless explicitly allowed. This means code that directly uses document.getElementById, $(), or other DOM selectors might have worked in older versions, but after an upgrade to a newer version (London, Madrid, New York, etc.), the same code will be blocked. In fact, upon upgrading, existing scripts get an Isolate Script flag (set to True) behind the scenes – they continue to work until you edit them. Once edited or created anew in a post-London instance, the strict mode kicks in and previously working DOM code starts failing. This change has caught many developers by surprise when an upgrade or a new instance suddenly causes $ is not a function errors.

  
  

• Missing configuration to allow jQuery/DOM (system property not set): ServiceNow provided a way to override this strict client scripting behavior via a system property. By default, the platform assumes the property glide.script.block.client.globals is true (meaning “block global client script access”) for global scripts. If this property remains enabled (or isn’t explicitly turned off), any new global client script will have $ blocked. In London and later, administrators can set this property to false to allow global DOM access, but if they haven’t, the restriction stays in effect. Similarly, in scoped applications, there is a scope-specific version of this property (e.g. <scope_name>.glide.script.block.client.globals). If those aren’t configured, scoped client scripts will also block global functions. In short, a ServiceNow instance with default security settings will prevent jQuery functions from executing in client scripts unless you explicitly disable the block. (Note: “Missing permissions” in this context doesn’t refer to user permissions, but rather system settings – for example, the Isolate Script field might not be visible to you until you configure the form, or you might not realize a system property needs changing.)

  
  

Understanding these causes helps target the appropriate fix. Next, we’ll explore proven solutions and workarounds for each scenario.

Verified Solutions and Workarounds

There are several ways to resolve the $ is not a function error in ServiceNow. The right approach depends on your use case – whether you want to use jQuery in that script or avoid it altogether – and your administrative access to change settings. Below are the verified solutions:

Solution 1: Disabling the “Isolate Script” Flag

If you need to use DOM manipulation or jQuery in a particular client script, the quickest fix is to turn off script isolation for that script. By setting Isolate Script = false, you allow the script to run in the global scope where $ and window objects are accessible. In other words, you’re opting that script out of the strict mode.

The Client Script form in ServiceNow (London release) with the Isolate script option highlighted. When this box is checked (True), the script is isolated from the global environment. Unchecking it (setting to False) will allow DOM access and jQuery/$ usage in that script.

To disable the Isolate Script flag on a client script, follow these steps:

1. Open the client script record that is causing the error (for example, navigate to the onChange Client Script in the form’s configuration).

   
   

2. Add the “Isolate script” field to the form if you don’t see it. You can do this by right-clicking the form header and selecting Configure → Form Layout. In the form layout, move Isolate script from the left column to the right (so it appears on the form), then save the form layout. (By default, this field might be hidden on older instances.)

   
   

3. Once the Isolate script checkbox is visible, uncheck it (set it to False). This means the script will not be isolated.

   
   

4. Save/Update the client script.

   
   

After this change, reload the form and test the functionality again. With isolation disabled, the global $ function should now be available to that script, and the error should disappear. In our earlier example, turning off Isolate script immediately resolved the onChange error and the script could manipulate the field as intended. Essentially, you are allowing that one script to run as if it were in a pre-London environment where DOM manipulation was permitted.

Note: Disabling isolation for a script means you are consciously bypassing a safety mechanism. This is generally fine for well-tested scripts, especially if you need functionality that ServiceNow’s APIs don’t provide. Just ensure that the script code is secure and won’t inadvertently affect other parts of the page. This solution is ideal when you have one or a few scripts that legitimately need to use $ or direct DOM access.

Solution 2: Using ServiceNow-Compatible JavaScript Instead of jQuery

Another approach is to remove the dependency on $ altogether by rewriting the client script using ServiceNow’s supported APIs and standard JavaScript. ServiceNow provides the GlideForm (g_form) API for form manipulations and the GlideUser (g_user) API for user/session info, among others. Often, you can achieve the same outcome without ever using jQuery. By doing so, your script will run in isolate mode without errors (since you’re no longer calling a blocked function).

Here are some strategies for replacing jQuery/DOM code with ServiceNow-friendly code:

• Use GlideForm methods for field operations: The g_form object offers many methods to show/hide fields, set values, change labels, display messages, etc., without touching the DOM directly. For example, instead of using jQuery to hide an element with $("#fieldId").hide(), you can call g_form.setDisplay('<field_name>', false) to hide a field by name. Instead of manipulating a field’s style via $().css(), you might use a GlideForm method or field decoration. ServiceNow explicitly encourages using these APIs rather than direct DOM calls for consistency across browsers and to ensure support in all interfaces.

  
  

• Leverage field decorations and messages: If your goal is to highlight a field or add an icon (such as a VIP star icon next to a name), use the built-in decoration APIs. For example, to mark a requester field as VIP, you can use:

  g_form.addDecoration('u_requester', 'icon-star', 'VIP User');

  This one line will add the star icon on the field’s label with a tooltip "VIP User", just like the out-of-box VIP indicator. You can also remove decorations with g_form.removeDecoration. Similarly, to give feedback or highlight text, consider using g_form.addInfoMessage() or g_form.addErrorMessage() to show a message, instead of, say, coloring a field red via DOM. These methods are part of the supported Client Script API and will work without needing jQuery.

  
  

• Use g_form to access field elements if absolutely needed: In some cases, you might need to tweak a specific style that isn’t covered by a GlideForm method. You can retrieve the actual HTML element for a field by using g_form.getControl('<field_name>'), which returns the input element (DOM node) for that field. From there, you can use standard JavaScript properties on that element (for example, g_form.getControl('u_requester').style.color = 'red'; to set the text color). This does involve a bit of DOM manipulation, but it’s done through a supported API call to get the element. Keep in mind that if Isolate script is true, direct DOM properties like element.style are not forbidden – what was forbidden was the global lookup of elements. By going through g_form, you’re operating within the allowed scope. (However, note that extensive DOM changes are still not recommended – use sparingly.)

  
  

• Avoid using $ for selectors or DOM traversal: Many times, scripts included $('someSelector') just to find an element or value on the form. In ServiceNow’s UI16 (and earlier UI), the $ was actually a Prototype library alias, not jQuery – which caused confusion for some who tried to use jQuery-specific features. In any case, it’s best to avoid $ entirely in client scripts now. If you need to query the DOM, use document.querySelector or getElementById in a non-isolated script, or structure your code to use provided APIs. For example, to get a reference field’s display value, use g_form.getDisplayValue('<field_name>') instead of trying to grab it from the DOM. To check if a user has a role (as in the example code), use g_user.hasRole('some_role') rather than a script trying to inspect elements.

  
  

By refactoring your script to use ServiceNow’s APIs and vanilla JS, you eliminate the root cause of the error (the blocked $ function). Your script will no longer trigger the strict mode protections, because it isn’t violating them. This is the preferred long-term solution – it makes your client scripts more upgrade-safe and compatible with different client environments. In fact, ServiceNow’s best practices explicitly state to “use g_form and related functions instead of $() or getElementById()… At all costs avoid using $().”. Direct DOM scripting can be brittle; it might work in one browser and break in another, or fail in new UIs. By using supported APIs, you ensure the code works consistently and is less likely to break when ServiceNow changes the UI. (For example, scripts that rely on internal DOM structure might not work in the Service Portal or Mobile apps at all, whereas GlideForm methods will.)

In summary, Solution 2 involves rewriting your client script so that it doesn’t depend on jQuery/$. This might take a bit more initial effort, but it pays off in stability. Once you remove $ from the script (and use GlideForm or other means), the “$ is not a function” error will vanish because you’re no longer calling that missing function.

Solution 3: Adjusting System Properties to Allow DOM Manipulation

This solution is a broader change: configure the system to allow all client scripts to use global DOM functions. ServiceNow introduced a system property in the London release to control the script isolation behavior globally. The property is called glide.script.block.client.globals. By default, it is effectively “true” (meaning block global client scripting). If you set this property to false, ServiceNow will not isolate new client scripts by default – effectively re-enabling access to window, $, and other global objects for all client scripts in that scope.

In an official statement, ServiceNow notes: “To disable this feature for all new globally-scoped client-side scripts set the system property glide.script.block.client.globals to false.”. This flips the default behavior so you don’t have to individually turn off Isolate Script on each script.

Here’s how to implement this solution:

1. Navigate to System Properties (you can type sys_properties.list in the Application Navigator filter to open the list of all properties, or go to System Properties > All).

   
   

2. Search for a property named glide.script.block.client.globals. If it doesn’t exist (many instances upgraded to London did not have it explicitly), you’ll need to create it.

   
   

3. Create a new property with the following details if necessary:

   • Name: glide.script.block.client.globals

   • Type: true/false (boolean)

   • Value: false (unchecked).

     
     

     Add a description like “Allow global client scripts to access DOM (disable script isolation)”.

     
     

4. Save the new property. This change takes effect immediately for any client scripts loaded thereafter. (You may need to clear your browser cache or do a hard refresh to ensure no old client script behaviors are cached.)

   
   

If your error is occurring in a scoped application (i.e., the client script belongs to a scoped app), you should create a similar property within that scope. The property name will be prefixed with the scope. For example, in the Customer Service (CSM) scope, the property would be sn_customerservice.glide.script.block.client.globals. You can create that by navigating to the application’s properties (switch to the application in Studio or via the scope picker, then add the property in that context). Setting it to false in a scope will allow scripts in that scope to also use global objects.

System property configuration for glide.script.block.client.globals (Global scope). Here the property is set to “false”, which disables the client script isolation globally. After this is set, new or edited client scripts will no longer be blocked from using jQuery, Prototype, or window objects.

After adjusting this property, you should find that client scripts no longer throw errors when using $. For example, if the property is false, even a new onChange script using jQuery will execute (though remember that out-of-box, $ in the platform UI is Prototype’s $ function, not jQuery – but Prototype’s $ for selecting elements will also work again). Essentially, you have globally opted out of the strict mode. One ServiceNow blog recommended setting this property false if you plan to continue using DOM access, to avoid issues when modifying older scripts.

Use caution with this approach: Disabling the script isolation globally means all client scripts (in that scope) can now use global variables and touch the DOM. This might be necessary for your environment, especially if you have many legacy scripts that would be tedious to refactor. However, you lose the protective layer that ServiceNow put in place. Make sure your developers are aware that they should still follow good practices (e.g., not inadvertently messing with the DOM in unsupported ways). Also, if ServiceNow introduces future enhancements around client script security, you’ll want to monitor those – but for now, setting glide.script.block.client.globals = false is an officially supported way to back out of the strict mode.

In summary, Solution 3 is about configuration: by toggling a system property, you allow $ and other functions globally, so the TypeError will not occur. This is a “broad stroke” fix that can save time if you have multiple scripts affected, but it should be done by an admin with consideration of the implications.

Solution 4: Debugging and Testing in Different Browsers

Sometimes, resolving client script errors requires a bit of debugging to pinpoint the exact cause and verify the fix. It’s good practice to use multiple browsers and developer tools to troubleshoot the issue:

• Use the Browser Developer Console: When the error appears, open the developer console (Chrome: F12 or Ctrl+Shift+J, Firefox: Ctrl+Shift+K, etc.) to see the full error stack trace. The console will show the “TypeError: $ is not a function” message and often indicate which script or line caused it. This can be more informative than the small banner or dialog in the UI. The developer console is a powerful tool to inspect runtime errors and even live-test code. As ServiceNow’s documentation notes, the browser console can be used to find and debug any client-side script errors on the page. By examining the stack trace, you might confirm that it’s your onChange client script and the line where $ was called that’s failing.

  
  

• Leverage ServiceNow’s debugging tools: In the main ServiceNow interface, you can enable the JavaScript Log and Field Watcher (via the settings gear icon > Developer tab) to help debug client scripts. The Field Watcher will show which client scripts are running on field changes and whether they complete successfully. If a script is failing, Field Watcher can identify it. You can also add temporary jslog() or console.log() statements in your script (if you can edit it) to trace execution – though in this particular error case, the script likely stops entirely at the $ call.

  
  

• Test in multiple browsers: It’s wise to run the form in more than one browser (e.g., Chrome, Firefox, Edge) to see if the behavior is consistent. In this case, because the root cause is ServiceNow’s script isolation, all modern browsers should exhibit the same error. If you ever found the error appears in one browser but not another, that could hint at a different issue (such as a browser-specific script or caching problem). Generally, $ is not a function due to script isolation will occur universally, but checking multiple browsers ensures that something like a browser extension or cached script isn’t giving a false impression. After implementing a fix (Solutions 1–3 above), test again in multiple browsers to confirm the error is truly resolved everywhere.

  
  

• Clear cache and try Incognito/Private mode: ServiceNow client script changes can sometimes be cached by the browser. If you disable the Isolate Script flag or change the system property and you still see errors, try clearing your browser cache or opening the application in an incognito/private window. This ensures you’re loading the latest client script definitions. Different browsers, by their nature, will have separate caches – so if it works in one browser after a change but not another, a caching issue might be why.

  
  

By thoroughly debugging and testing in various environments, you can be confident that the solution you applied is effective. This process can also reveal any other underlying issues. For instance, while debugging, you might notice other JavaScript errors on the page that need attention. The goal is to ensure that after you make changes (like un-isolating the script or refactoring the code), no further errors appear in the console and the script functions as intended.

In summary, Solution 4 isn’t a direct “fix” to the $ is not a function error, but it’s an essential practice: use the tools at your disposal to verify the problem and test the outcome. This way, you not only fix the immediate error but also gain confidence that it’s solved in all scenarios.

Best Practices for Avoiding Similar Errors in the Future

To prevent encountering errors like this in the future (especially after ServiceNow version upgrades or script changes), it’s wise to adopt some best practices in your client-side development:

• Use ServiceNow’s supported APIs for client scripting: Always prefer the GlideForm (g_form) methods, GlideUser (g_user), GlideAjax, etc., for any operations they can accomplish. These APIs are designed to work in the ServiceNow client environment and will remain supported across versions. By using them, you avoid needing to access the raw DOM in most cases. For example, use g_form.setValue() to set field values, g_form.setVisible()/setDisplay() to show or hide fields, g_form.addOption() to manipulate choice lists, and so on. This way, your code will not be impacted by the script isolation, since you’re not breaking the rules. ServiceNow’s own best-practice guides urge developers to avoid direct DOM manipulation in client scripts.

  
  

• Avoid direct DOM calls (document.getElementById, $(), etc.) unless absolutely necessary: Any time you find yourself writing code to traverse or modify the HTML directly, ask if there’s a GlideForm alternative. Direct DOM code is considered an unsupported customization – it may work today but could break with a future ServiceNow UI change. In fact, such code tends to “break on any GUI update from ServiceNow” and is not supported on interfaces like the Service Portal or mobile apps. The introduction of the Isolate Script mechanism in London is a testament to ServiceNow steering developers away from these practices. If you must use DOM methods (perhaps for a very niche requirement), document those scripts well and be prepared to adjust them when upgrading, as they are more fragile.

  
  

• Keep the “Isolate script” setting in mind when developing: In modern instances, whenever you create a new client script or client-side script include, remember that Isolate script will be true by default. If you try to use unsupported code, you’ll hit errors immediately. If you intentionally need to do something outside the norm, you have the option to turn off isolation for that script (as discussed). But as a rule of thumb, try to write your scripts such that they don’t require turning isolation off. This will make them more future-proof. Encouraging a coding standard in your team to not use global $ or window in client scripts can save time in the long run.

  
  

• Leverage out-of-box capabilities and UI Policies: Sometimes what you’re trying to achieve with a client script can be done via a UI Policy or an out-of-box feature. For example, if the goal is to highlight VIP users, ServiceNow might already have a field decoration or a client script OOB that does it (as in the Incident form VIP icon). Where possible, use those instead of custom DOM manipulation. The more you stick to supported configurations, the less likely you’ll run into issues with upgrades.

  
  

• Stay informed on ServiceNow updates: As seen with the London release, ServiceNow can introduce changes that affect custom scripts. It’s a good practice to read the release notes and developer blog posts for each new version. Changes to client-side scripting (like this isolation feature) are usually documented in release notes or knowledge articles (e.g., KB0694479 was a knowledge article specifically about the new DOM security in London). By knowing these changes in advance, you can test your instance after an upgrade and proactively fix any script that might break. Joining the ServiceNow community forums or following their official blog can keep you informed – for instance, the “Isolate Script in London” blog post explained why some scripts stopped working and how to handle it. Staying up-to-date will help you adapt your solutions to ServiceNow’s evolving platform.

  
  

• Test custom client scripts in multiple environments: If your organization uses different interfaces (Service Portal, Classic UI, Agent Workspace), test your client scripts in all relevant interfaces. A script that uses g_form will work in the classic UI, but not in Service Portal (which uses a different API – you’d need to use the spClient script APIs). Meanwhile, a script that directly pokes the DOM might work in classic UI (if isolation is off) but definitely won’t in Service Portal or Workspace. Being mindful of where your code runs will help you avoid deploying scripts that cause errors in certain contexts.

  
  

By following these best practices, you’ll minimize the chances of running into the “$ is not a function” error or similar issues. Your client scripts will be more robust against ServiceNow’s security settings and version changes. In essence, write scripts that play by ServiceNow’s rules, and you won’t have to fight against the platform.

Conclusion

The “onChange script error: TypeError: $ is not a function” in ServiceNow is a common hurdle that stems from ServiceNow’s client-side scripting security and best practice enforcement. We’ve seen that it primarily occurs because the platform, by default, blocks access to the $ function (jQuery/Prototype) in client scripts, especially in newer releases or when the Isolate Script setting is enabled. This can disrupt custom form behaviors that rely on DOM manipulation.

Fortunately, there are clear solutions. For a quick fix on a single script, disabling the Isolate Script flag will re-enable global DOM access for that script, eliminating the error. For a longer-term or broader fix, refactoring your code to use ServiceNow’s GlideForm API and avoid jQuery is highly effective – it not only solves the error but aligns your script with ServiceNow’s supported practices. We also discussed enabling DOM access globally via a system property for cases where you have many scripts to handle (though this should be done with caution). Throughout the process, using debugging techniques and testing across browsers ensures that the issue is fully resolved and no new errors are introduced.

In addressing this error, we’ve also touched on the importance of writing client scripts that are upgrade-safe and compliant with ServiceNow’s guidelines. The introduction of script isolation in the London release was a push towards more stable and secure client scripts. As a developer or administrator, adapting to these changes – by updating scripts and following best practices – will save you headaches with future upgrades.

Key takeaways: If you see “$ is not a function” in a ServiceNow client script, remember to check the Isolate Script setting and consider the scope in which your code runs. Use the solutions above to restore your functionality. Going forward, try to design your client-side solutions using the platform’s APIs (like g_form) and you’ll likely never encounter this error again.

By applying the solutions and guidelines discussed, users encountering this issue can confidently modify their ServiceNow client scripts without fear of the dreaded TypeError. Happy scripting, and always keep an eye on those release notes for changes that may affect your customizations!