Next-Gen Scripting: Why Asynchronous GlideAjax Still Rules the AI Era

There's an interesting thing happening inside ServiceNow development teams right now. AI is being layered into everything, Now Assist, Agentforce-style automation, predictive intelligence across workflows. And yet, the fundamentals that make those experiences actually work for the people using them haven't changed at all.

Asynchronous GlideAjax is still the backbone of performant, responsible client-server scripting in ServiceNow. If anything, the rise of AI-driven workflows makes understanding it more important, not less.

What Is GlideAjax in ServiceNow?

GlideAjax is a client-side API in ServiceNow that allows client scripts to communicate with server-side Script without reloading the page. In plain terms: it's how you get data from the server while the user is doing something, without freezing everything while you wait.

The full name, Asynchronous JavaScript and XML, gives away the core concept. Instead of the browser sitting idle while it waits for a server response, the request goes out, the rest of the script keeps running, and the response comes back and triggers a callback function when it's ready.

That callback pattern is the thing most developers either learn properly early on, or spend years working around.

Synchronous vs Asynchronous, Why It Actually Matters

ServiceNow gives you two ways to use GlideAjax:

• Synchronous - getXMLWait() The browser stops. It waits for the server to respond. Nothing else happens until that response arrives. Your form freezes. Your user stares at it. For most scenarios, this is a bad experience and a known performance problem.
• Asynchronous - getXML() with a callback function The request fires. The script keeps executing. When the server responds, the callback runs. The UI stays responsive throughout.

The ServiceNow community and official training have been consistent on this for years: always prefer asynchronous GlideAjax. The only legitimate exception is an onSubmit client script, where you genuinely need to block form submission until you have a validated server response. Outside of that specific scenario, synchronous calls are a performance anti-pattern.

And yet, as a May 2026 ServiceNow community discussion pointed out, even ServiceNow's own out-of-box scripts from the Zurich release are still getting flagged by Instance Scan for using client-side GlideRecord instead of GlideAjax. The double standard is frustrating, but it reinforces the point: the standard exists for good reason, and well-maintained production instances follow it.

How Asynchronous GlideAjax Works in Practice

The structure of a GlideAjax call always has two parts: the client script that makes the request, and the server-side Script Include that handles it.

On the client side, you create a new GlideAjax object referencing the name of your Script Include, add any parameters you need the server to receive, a user ID, a field value, a filter condition, and then call getXML() with a callback function. That callback is what runs when the server responds. The form stays live throughout. The user isn't waiting.

On the server side, the Script Include retrieves those parameters, runs whatever logic or database query is needed, and returns a response. The key thing many developers miss: the Script Include must be explicitly marked as Client Callable in ServiceNow, otherwise the call will simply fail with no useful error on the client side.

A few things that make a real difference in how well this works:

• Pass only what the server actually needs, not the entire form state
• Return only what the client actually needs, a boolean, a value, a short JSON object
• Keep each Script Include focused on one logical domain rather than building one giant catch-all include
• For complex return data, JSON stringification on the server and parsing on the client keeps responses clean and predictable

Why Asynchronous GlideAjax Matters More in an AI-Era Platform

Here's the thing about AI workflows in ServiceNow. Now Assist, predictive intelligence, AI-assisted routing, all of these rely on fast, responsive UIs that don't block while background operations complete. If your client scripts are synchronously blocking the browser while waiting for server data, you're creating a friction point that undermines the whole experience.

ServiceNow's machine learning work at their best when the underlying scripting architecture is solid. Asynchronous GlideAjax is part of that foundation, it's how you keep the user experience fluid while the platform is doing real work behind the scenes.

The architecture principle holds even more firmly when you're building against ServiceNow's broader module ecosystem, Service Portal, the Next Experience UI, mobile agent apps. Each of these environments has different behaviour around client-side scripts, and asynchronous GlideAjax patterns are the ones that travel cleanly across all of them.

Scripting Best Practices That Hold Up in 2026

The ServiceNow developer community has converged on a fairly consistent set of practices around GlideAjax. Most of these are not new, but they're worth restating because the codebases where they're ignored are the ones generating the most expensive technical debt.

• Never use GlideRecord in a client script. Full stop. It puts direct database queries through the browser, bypasses proper server-side logic encapsulation, and creates performance problems at scale. GlideAjax exists precisely to prevent this. The server does the work; the client gets the answer.
• Log server-side errors with gs.error() inside your Script Include methods. Client-side debugging of an asynchronous response is painful when you don't know whether the problem is in the request, the Script Include logic, or the data returned.
• Test your Script Include independently before wiring it to a client script. If the method doesn't work when called directly, no amount of GlideAjax debugging will fix it.
• Wrap GlideAjax calls in utility functions when the same pattern repeats across multiple client scripts. A centralised AJAX utility, as described in ServiceNow's Dynamic Script Include patterns, reduces duplication and makes future maintenance significantly easier.
• Return the minimum viable response. The larger the payload coming back from the server, the slower the perceived response. If you only need a boolean, return a boolean. If you need a few field values, return those specifically, not the full record.

The Bigger Picture: Clean Scripting as a Foundation for AI Integration

There's a version of this conversation that's purely technical, syntax, patterns, debugging. But the more important version is architectural.

When an organisation is building on ServiceNow and starting to layer in AI capabilities, custom API integrations, AI and ML development solutions, Now Assist extensions, predictive routing, the quality of the underlying scripting directly affects what's possible. Poorly structured client scripts that use synchronous calls, expose server-side logic unnecessarily, or rely on GlideRecord in the browser aren't just a code smell. They're a limitation on what you can build on top of them.

ServiceNow software development done well means the foundation is solid enough that AI capabilities can be added without rebuilding everything underneath them. Asynchronous GlideAjax isn't exciting, it's plumbing. But the best implementations are built on good plumbing.

At Dotsquares, we work with organisations building and extending their ServiceNow environments, from custom API development to ServiceNow managed service and AI-ready platform architecture. If your ServiceNow scripting practices need a review before your next build phase, that's a conversation worth having.