Avoid GlideRecord calls in client-side scripts

Client-side GlideRecord calls are synchronous and block the entire browser UI while waiting for the server response. In scoped applications, they fail completely due to security restrictions. The GlideAjax pattern solves both problems by moving database queries to server-side Script Includes and using asynchronous callbacks to handle responses without freezing the interface. Most developers attempt this migration by simply wrapping their existing query logic, but the async nature requires restructuring your code flow around callbacks rather than sequential execution.

When to use this pattern

• When you need to populate fields based on user input in onChange client scripts
• When validating field values against database records in real-time
• When building scoped applications that need database access from client scripts
• When you need display values from reference fields without additional round trips

When NOT to use this pattern

• Don't use for simple reference field lookups — use g_form.getReference() instead
• Don't use for complex business logic that belongs in Business Rules or server-side validation
• Don't use when you need guaranteed data consistency — client validation can always be bypassed
• Don't use for queries that return large result sets — the JSON response will bog down the client

Key behaviors and gotchas

• The Script Include must extend AbstractAjaxProcessor and be marked as Client Callable
• Always check for isLoading parameter to avoid firing on form load when field has existing value
• Use JSON.stringify() and JSON.parse() for complex data — string concatenation breaks with special characters
• The response is always a string — 'null' and null are different values you must handle separately
• Server-side queries respect ACLs and domain separation based on the current user's context
• Use setLimit(1) when you only need one record — prevents unnecessary data transfer and processing