SuiteScript
May 20, 2026

Realtime Asynchronous Processing in NetSuite

Creative solutions for triggering the processing of custom records from within a User Event Script

Realtime Asynchronous Processing in NetSuite

I recently came across a Reddit post where the OP was asking about the best way to handle bulk creation of custom records inside of a user event. The requirements for the request were as follows:

Upon creation of a Credit Memo, a custom record parent along with a dynamic amount of child custom records should be created.

OP had initially tried to do this directly in the user event, but concluded it was too heavy an operation. Granted this kind of processing in user events is usually not recommended, but still worth testing as 1-3s processing time may sometimes be acceptable especially if the user event is limited to certain contexts only). OP then resorted to using scheduled scripts but faced issues due to multiple users creating Credit Memos simultaneously introducing the need for multiple script deployments which was also not ideal.

The real-time nature of the transaction was identified as a constraint, and so periodic processing was not preferrable.

Some proposals in the comments included the following:

  • Using a Restlet to conduct the processing (still synchronous and an additional network hop)
  • A Map/Reduce running every 15 minutes and picking up the respective credit memos for processing independently (periodic, not real-time)
  • A combination of a scheduled Map/Reduce and an on-demand Map/Reduce working in tandem to maximise uptime processing efficiency (solid, but again not quite real-time)

Most of the LLMs also converged on the Map/Reduce custom record processing pattern.  The OP's problem however reminded me of a couple of other ways to achieve near real-time asynchronous processing.  It also presented the opportunity for me to test a new method of batch processing introduced in the 2026.1 release. Moreover, I think a task like this can be achieved with less boilerplate, without having to coordinate across 3-5 deployment records, and without hogging your all important Map/Reduce resources.

So, without further ado, here are two out-of-the-box ways you can achieve quasi-real-time asynchronous batch processing. The asynchronous nature of these approaches is what makes them viable for being wired into user events without worrying about processing time.

Workflow triggered through Task module.

Set up a workflow with a workflow action script that does the custom record parent-child record creation, and have the user event trigger the workflow using the task module to set off a task of type WORKFLOW_TRIGGER

The user event completes instantaneously, and the workflow is placed into a queue for processing.  The workflow action itself completed in near real-time in an account with not much activity.

Batch Operation using REST Web Services

From the dawn of its release, SuiteTalk REST has held much promise. However, there were always serious trade-offs to be had when trying to make use of it for some production requirements:

- Limited amount of filters,

- little control over response projection,

- having to make several round trips to get the job done, and

- partial support for some record types. 

I’ve always had a love-hate relationship with HATEOAS.

After incremental improvements with each new major NetSuite release, SuiteTalk REST is looking in great shape.  And it's the latest support for homogeneous batch operations from the 2026.1 release, which got me extremely excited.  

Apart from the obvious use cases for long-running migrations and processing data en masse without having to design custom integrations, this ability opens the door to low-effort, 'outsourced' processing of records.  Stuff that would normally require reusing the age-old pattern of creating custom record jobs including data to be picked up by Scheduled and Map/Reduce scripts for processing.

So, like the Workflow task trigger option, we return early from the user event and simply submit an asynchronous batch operation to the REST web services endpoint to create any amount of custom records necessary.  By any amount I really mean 100 per batch, but you could always submit multiple HTTP requests if needs be, and if you're processing more than 100 records for a realtime operation, then maybe periodic processing is indeed the better mode.

In any case, the Batch REST processing completed incredibly fast in my test account. 

There are no solutions, only trade-offs

Although every account will have its own unique distribution of processing across available services. NetSuite does caveat that overworking the REST Async processors might result in degradation of running scripts although I would imagine you'd have to really pummel the async processors for this to happen.

Now, like with everything, some of the effort you save in building custom scripts to do the processing you may incur with ensuring proper error handling and idempotency around using these alternate mechanisms.  

But I am a firm believer in making use of the full range of services NetSuite gives you for going about your customization business!