Client-side code should not use synchronous AJAX ; Really ?

[Fred Jean]

Hello,

It is a well known, and I believe accepted, good practice to avoid synchronous AJAX in client script.  This is for reasons such as UI responsiveness and perf bottleneck. And having such synchronous AJAX will trigger Healthscan findings.

While reviewing such Healthscan findings where a catalog client script was using a synchronous call, I discussed the topic with the script developer to know if there was any reason to do so.

The reason I was given was to avoid the user from submitting the form before we get the Ajax answer to update other form fields.  (yes, the user would have to be very quick or the network very slow, but it can happen).  So here we want to avoid submission of incomplete or inconsistant data.

So then I thought, doesn't this actually also apply to like 90% of the client scripts using AJAX calls ? Don't we mostly use AJAX to update other fields ? Isn't it an issue most of the time if a form is submitted before the script and AJAX does its job ? So, isn't it actually a good thing to have synchronous calls and get the form blocked (yes I know there are other ways to achieve this) ?

What do you think ?

[vignesh parthib]

Hi Tera

Best practices instead:

• Use asynchronous AJAX, but control user actions while it runs:

  • Disable submit buttons until updates complete.

  • Show loading indicators.

  • Block submission with client-side validation until AJAX finishes.

• Use promises, async/await, or callbacks to ensure form submission happens only after AJAX completes.

• Always validate data on the server, handling any premature or invalid submissions safely.

What about most client scripts using AJAX?

They should follow the same approach—never rely on synchronous calls. Instead, design the UI to prevent submission until async updates finish, providing user feedback throughout.

[Fred Jean]

I agree with those recommendations (though having loading indicator would be overkill most of the time). Making sync calls is a cheap/dirty way to do that.

The thing is it seems to me most client scripts with AJAX would then need that mechanism to ensure proper data is submitted, so when that mechanism is not implemented (and most of the time it isn't), it could still be better to keep the calls synchronous.

[vignesh parthib]

Hi Tera,

Best practices instead:

Use asynchronous AJAX, but control user actions while it runs

• Disable submit buttons until updates complete
• Show loading indicators.
• Block submission with client-side validation until AJAX finishes.
•  
• Use promises, async/await, or callbacks to ensure form submission happens only after AJAX completes.
• Always validate data on the server, handling any premature or invalid submissions safely.

What about most client scripts using AJAX?

They should follow the same approach—never rely on synchronous calls. Instead, design the UI to prevent submission until async updates finish, providing user feedback throughout.

[M Iftikhar]

@Fred Jean 
Synchronous AJAX may feel safer, but it hurts performance, freezes the UI, and is flagged by HealthScan.
Best practice is to always use asynchronous calls (GlideAjax, getReference with callback) and control submission with onSubmit. Leverage g_scratchpad to preload values and avoid unnecessary calls.
If timing is a concern, use onSubmit to prevent submission and show an info message like “Please wait.. loading required data” until the async call finishes.

https://www.servicenow.com/community/queensland-snug/client-script-best-practices/ba-p/2273951 

Thanks & Regards,
Muhammad Iftikhar

If my response helped, please mark it as the accepted solution so others can benefit as well.