Discussion: Why is this OOB Client Script using GlideRecord?

[Ajay_saitej]

For years, the ServiceNow developer community and official training modules have hammered home a golden rule: Avoid using GlideRecord in Client Scripts. We are taught to use GlideAjax with asynchronous XMLHttpRequests to keep the browser responsive and follow best practices.

However, while digging through some OOB configurations after Zurich upgrade, I stumbled upon a KB article -https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB2676169  and when I checked I found that client Script that seems to ignore the "Standard" playbook.

 

Below is an OOB Client Script snippet that performs a lookup on the sys_user_grmember table:

JavaScript

function onChange(control, oldValue, newValue, isLoading, isTemplate) {
    if (isLoading)
        return;

    if (oldValue != newValue)
        g_scratchpad.formValue = newValue;

    if (newValue === '' || newValue == null || oldValue != newValue || newValue != g_scratchpad.formValue) {
        if (newValue && g_form.getValue("assigned_to")) {
            // Found: Client-side GlideRecord query
            var groupLookupGr = new GlideRecord('sys_user_grmember');
            groupLookupGr.addQuery('group', newValue);
            groupLookupGr.addQuery('user', g_form.getValue("assigned_to"));
            groupLookupGr.setLimit(1);
            groupLookupGr.query(groupLookupCallback); 
        } else {
            g_form.setValue("assigned_to", "");
        }
    }
}

function groupLookupCallback(groupLookupGr) {
    if (!groupLookupGr.hasNext())
        g_form.setValue("assigned_to", "");
}

1. Client-Side GlideRecord: While it uses a callback function (making it asynchronous), the official recommendation has long shifted toward GlideAjax for better security control and performance optimization.

2. Maintenance: If a junior developer sees this, they might assume GlideRecord on the client side is the preferred way to query data.

3. We often see these scripts flagged during ACE (Automated Checking Entity) reports or HealthScans, yet they persist in the core platform.

Discussion Points

• Is it time to relax the "No GlideRecord on Client" rule if a callback is used?

• Or should ServiceNow prioritize refactoring these legacy OOB scripts to meet current 2026 standards?

• Does the simplicity of this approach outweigh the overhead of setting up a Script Include for a simple 1-line check?

I’d love to hear the thoughts of the experts and the product teams on why this pattern remains the standard for some OOB features

@Earl Duque @laurenmcman @Travis Toulson @Tim Woodruff @Mark Roethof 
#ServiceNow #BestPractices #ClientScript #Scripting #GlideRecord #Development

[Ankur Bawiskar]

@Ajay_saitej 

yes it's not recommended but the GlideRecord has a callback method which doesn't block browser and hence they must have used it in client side

There are many examples in OOTB scripts which don't follow best practices but they are still there.

💡 If my response helped, please mark it as correct ✅ and close the thread 🔒— this helps future readers find the solution faster! 🙏

[Tim Woodruff]

First, let me just say- please do not tag a bunch of random people in the community. That comes off as kind of pushy and somewhat rude and presumptuous.

Instead, if you want to get our opinions, feel free to reach out to us directly! Send us a message on LinkedIn and ask us what we think of your post. We're all pretty friendly, at least when we have the time to be.

On that note, as far as I can tell it doesn't look like hashtags actually work on the community so... I would remove those.

In general, it looks like this post may have been written with AI and then copied and pasted to multiple places. Which is a really bad look.

All of that said, you make a really excellent point; one I agree with wholeheartedly. SN needs to refactor their OOB code - including, but NOT EXCLUSIVELY, the code we can all see in our instances. 

They desperately need to improve their poorly written, poorly performing out-of-box code to at a bare minimum be compatible with the instance scan scripts. They need to write a lot more of those instance scan checkers as well. The community has provided hundreds, if not thousands, of instance health scan scripts literally for free, and ServiceNow is welcome to just take any or all of them and apply them to their own code so they can find all of the instances of bad out-of-box code that they're able to, and fix them all - typically super easily! The vast majority of these issues are simple one-line changes that could easily be done by a find and replace script with a human approving each replacement after 10 seconds of manual review. Hell, they could even have their precious AI do it and only bubble up the changes about which it's particularly unsure to a human.

Speaking of AI, why the hell do they not provide these instance scan scripts to the Build Agent as an available tool call or MCP or something? It can analyze its own output to ensure that it's compatible with the instance health scan checks, or at least to be able to respond to health scan findings in cases where the finding is not necessarily applicable or there is no better way or something. That seems like an absolute no-brainer, and after seeing the unbelievably horrific, abhorrent, distressing, and gratuitously bad code output by the Build Agent, I can tell you with confidence that it desperately needs it!