question Using shared catalog client scripts in Community Central forum

Using shared catalog client scripts

John Spencer — Sun, 08 Mar 2026 03:36:23 GMT

Hello All,

Is there a 'reliable' mechanism to allow 'shared' code between / among catalog client scripts in the same catalog item?

That is, a client catalog script would load with the intent of being able to be called by another client catalog script in the same catalog item. Presently using Yokohama (patch 10).

Thanks in advance,

John Spencer

Re: Using shared catalog client scripts

Juhi Poddar — Sun, 08 Mar 2026 03:50:27 GMT

Hello @John Spencer

You could consider using a UI Script to store the shared functions and then call those functions from your Catalog Client Scripts. This is a reliable way to reuse client-side code across multiple scripts and helps avoid duplicating logic.

Hope this helps!

"If you found my answer helpful, please like and mark it as an "accepted solution". It helps future readers to locate the solution easily and supports the community!"

Thank You
Juhi Poddar

Re: Using shared catalog client scripts

Ankur Bawiskar — Sun, 08 Mar 2026 03:51:08 GMT

@John Spencer

there is no available OOTB mechanism to control shared code between catalog client scripts.

You need to handle this with your development experience and customer requirement and try to avoid conflicting scripts.

Try to keep script in single onLoad always and you can write onChange script on variable based on requirement.
💡 If my response helped, please mark it as correct ✅ and close the thread 🔒— this helps future readers find the solution faster! 🙏

Re: Using shared catalog client scripts

Tanushree Maiti — Sun, 08 Mar 2026 04:18:26 GMT

Hi ,

In ServiceNow, a UI Script is a reusable block of client-side JavaScript code, similar to how a Script Include works for server-side code. They are used to promote code reusability and maintainability by centralizing common client-side functions like Client Scripts and Catalog Client Scripts.

Ref: https://www.servicenow.com/docs/r/api-reference/scripts/c_UIScripts.html

https://www.servicenow.com/community/itsm-forum/what-is-ui-script-and-give-me-any-example-where-you-used-ui/td-p/925566

Re: Using shared catalog client scripts

jeffreybell — Sun, 08 Mar 2026 14:12:54 GMT

Ankur’s answer is the most practical. While there is almost always a way to accomplish something through customization (for example, calling another Catalog Client Script from a client script), this pattern is generally discouraged. If you find yourself needing it, there is usually a better out-of-the-box approach, or the underlying use case should be reconsidered.

Ask first: why is shared client logic required? Often the goal is to avoid repeating the same logic, such as recalculations triggered by multiple onChange scripts.

If you truly need shared logic (e.g., calculations like infrastructure sizing for CPU or memory), a better approach is to implement the logic in a client-callable Script Include and invoke it via GlideAjax. Keep logic in client scripts only when the behavior is purely UI-driven.

Re: Using shared catalog client scripts

balu_one — Fri, 13 Mar 2026 12:45:21 GMT

Hi John,

I think the approach of using the shared function in the onLoad script works fine. But it is not a documented approach as such, and I have seen it in this community post. The credit goes to them.

Steps:

Create an onLoad script which stores the reusable shared code. Say something like this

function onLoad() { } /* Shared functions */ sayHello = function (msg) { alert('Hello ' + msg); }

Create an onChange script that calls the Shared functions

function onChange(control, oldValue, newValue, isLoading) { if (isLoading || newValue == '') { return; } sayHello('John'); }

This should work in Native UI and Service Portal. I'm not sure about Workspaces and Mobile.

And also note, the shared functions must be written in the following format to make it work in Service Portal.

function_name = function () { // Do something }

I agree with Jeffrey Bell. The main reason we’d need this is when multiple onChange scripts share the same logic. However, I’ve also encountered forms that require certain validations before even initiating an Ajax call. It can be quite a tricky situation, I must say.

Sometimes I wonder why wouldn't ServiceNow just implement

A mechanism to have form only reusable object (similar to g_scratchpad) within Catalog form.
Allow variables that exist only on the Catalog Form, without being submitted or included in the Requested Item

They may seem so minor, but they significantly enhance the overall strength of the Form’s client-side capabilities.

Thanks
Balu