Why getXMLWait() Is NOT Supported in Workspace & Service Portal (and the Right Way to Handle OnSubmit Validation)
Introduction
Many ServiceNow developers rely on getXMLWait() in onSubmit Client Scripts to perform server-side validation before allowing a record to be submitted. This approach works only in the Native UI.
However, when the same script is used in:
- Agent Workspace / Configurable Workspace
- Service Portal
…it silently fails or behaves unpredictably.
This article explains:
- Why getXMLWait() is not supported outside the Native UI
- Common but flawed workarounds (extra checkbox fields)
- A clean, Workspace-safe async solution that works in Native UI, Workspace, and Portal
- A refined, production-ready version of the code
Why getXMLWait() Is NOT Supported in Workspace & Service Portal
getXMLWait() performs a synchronous GlideAjax call, meaning the browser halts execution and waits for the server response before continuing.
What Happens in Native UI
In UI16 (Native UI), the platform still allows synchronous browser operations:
- The UI thread is temporarily blocked
- The server responds
- getAnswer() is returned immediately
- Form submission continues or stops based on the response
This is why many legacy client scripts using getXMLWait() appear to work fine in the Native UI.
The Real Problem in Workspace & Portal
Agent Workspace and Service Portal are built on modern, asynchronous UI frameworks designed for:
- Non-blocking execution
- Better performance
- Improved user experience
Because of this architecture:
Blocking (synchronous) calls are explicitly unsupported
- getXMLWait() is either ignored or fails silently
- getAnswer() returns "null" or an empty value
- Server-side validation logic never executes
This behavior is expected and by design — not a bug.
-> Supported only in: Native UI (UI16) -> Not supported in: Agent Workspace, Configurable Workspace, Service Portal
The Common (But Problematic) Workaround
When developers realize getXMLWait() does not work in Workspace or Portal, a typical workaround is implemented:
Many developers solve this by:
- Creating an extra checkbox field (e.g., validation_passed)
- Using an onChange Client Script to set it
- Checking the checkbox during submit
Why This Is a Bad Practice
Adds unnecessary fields to the table
- Pollutes the data model
- Makes the logic harder to maintain
- Breaks encapsulation
We can do better — without adding any extra fields.
The Correct Pattern: Async Validation onSubmit
The right solution is:
- Use getXMLAnswer(callback) (async)
- Prevent default submit
- Re-submit programmatically after validation
- Use g_scratchpad to prevent infinite loops
This pattern works in:
- Native UI
- Agent Workspace
- Service Portal
Use Case Explained
In this example, we:
- Extract Account and Contact values from a template value field
- Call a Script Include (HierarchyValidation)
- Validate hierarchy on the server
- Block submission if invalid
Native UI‑Only Version (NOT Recommended) getXMLWait()
This version works only in UI16 and should be avoided for modern apps:
function onSubmit() {
var qualifier = g_form.getValue('template');
var account = '';
var contact = '';
if (qualifier) {
qualifier.split('^').forEach(function (p) {
if (!p || p === 'EQ') return;
var pair = p.split('=');
if (pair.length !== 2) return;
if (pair[0] === 'account') account = pair[1];
if (pair[0] === 'contact') contact = pair[1];
});
var ga = new GlideAjax('HierarchyValidation');
ga.addParam('sysparm_name', 'validate');
ga.addParam('sysparm_account', account);
ga.addParam('sysparm_contact', contact);
// Synchronous call (UI16 only)
ga.getXMLWait();
var response = ga.getAnswer();
if (response === 'false') {
g_form.addErrorMessage('The selected Account and Contact do not follow the correct hierarchy.');
return false;
}
}
return true;
}
Output Results:
In Workspace, the form is submitted without executing the validation
Workspace‑Safe OnSubmit Client Script (Recommended)
function onSubmit() {
// Prevent infinite recursion
if (g_scratchpad.hierarchyValidationDone)
return true;
var qualifier = g_form.getValue('template');
var account = '';
var contact = '';
// Parse templaten value string
// account=xxx^contact=yyy^active=true^EQ
if (qualifier) {
qualifier.split('^').forEach(function (part) {
if (!part || part === 'EQ') return;
var pair = part.split('=');
if (pair.length !== 2) return;
if (pair[0] === 'account') account = pair[1];
if (pair[0] === 'contact') contact = pair[1];
});
}
// Async GlideAjax validation
var ga = new GlideAjax('global.HierarchyValidation');
ga.addParam('sysparm_name', 'validate');
ga.addParam('sysparm_account', account);
ga.addParam('sysparm_contact', contact);
ga.getXMLAnswer(function (response) {
if (response === 'false') {
g_form.addErrorMessage('The selected Account and Contact do not follow the correct hierarchy.');
return;
}
// Mark validation completed
g_scratchpad.hierarchyValidationDone = true;
// Re-submit form (required for Workspace & Portal)
g_form.submit(g_form.getActionName());
});
// Stop normal submit until async validation completes
return false;
}
Output Result:
Workspace
Native UI
With this implementation, form submission is temporarily restricted in Native UI, Workspace, and Service Portal while the validation is executed in a controlled flow. This approach is especially useful for enforcing validations in Workspace Record creation and updation, Catalog Items and Record Producers.
