NetSuite Event Subscriber: it tells you where to look

On August 21 I asked the NetSuite Professionals Slack whether anyone had an Event Subscriber script running. project:validate was rejecting the object with "Platform Events are not enabled for this account," a feature that appears nowhere in Enable Features. Another developer later reported the same error in five 2026.2 accounts. My test account needed a support case before the object would deploy.

I usually let a new script type sit for two or three releases before I build on it. This one is worth testing early, because it changes where follow-up logic lives. But an Event Subscriber doesn't tell you what happened. It tells you where to look, a minute or four later.

What you actually get

Oracle's description is short: Event Subscriber scripts "run asynchronously after supported events occur," for "follow-up processing that does not need to finish before the originating record operation completes." You write a SuiteScript 2.1 file with one entry point, handle(options), and an SDF eventsubscriber object that says which events call it:

<criterion>
  <domain>RECORD</domain>
  <type>CREATED</type>
  <parameters>
    <parameter>
      <name>RECORDTYPE</name>
      <operator>EQ</operator>
      <value>SALESORDER</value>
    </parameter>
  </parameters>
</criterion>

That's the whole filter language. RECORD is the only domain, CREATED, UPDATED and DELETED are the only types, and RECORDTYPE with EQ is the only parameter. No field conditions, no execution-context filter. It's SDF-only, too: Oracle's own sample fails Create Script Record in the UI.

I deployed one to a NetSuite 2026.2 test account and logged everything it could see. Here is the complete options object, as JSON.stringify returned it:

{"context":{"recordType":"CUSTOMRECORD_EVSUB_PROBE"},"payload":{"recordId":"1"}}

A record type and a string ID. No event type, no old values, no new values. Not even consistent casing: the same subscriber received CUSTOMRECORD_EVSUB_PROBE, JournalEntry and salesOrder. Inside handle, runtime.executionContext is EVENTSUBSCRIBER, the script runs as the user who saved the record, and it starts with 1,000 usage units, matching Oracle's documented limit. Oracle gives it 300 seconds.

It's also slow by design. Across the 17 runs I could time, the delay between the save and handle starting ranged from 62 seconds to 259 seconds. Fourteen saves made over five seconds produced 15 events, and all 15 handlers started within a second of each other, about four minutes later, and not in save order.

Where it beats a user event

It's off the save path. A user event's afterSubmit runs inside the request the user is waiting on. Oracle says the subscriber's logic "does not delay the operation." The obvious candidates are the slow, optional things that sit at the end of afterSubmit today: notifications, updates to related records, calls to other systems. One developer in that Slack thread uses it to post each event to a topic and lets the subscribing system decide what to do.

It sees saves a user event can't. NetSuite doesn't run user events on a record that another user event creates. In my test, a user event's afterSubmit created a child record. No user event fired for the child. The subscriber did. It also fired for UI saves, record.save from a Suitelet, and record.submitFields. Follow-up logic that today depends on every writer remembering to trigger it can subscribe to the record instead.

It doesn't trigger itself. My other question in that thread was the feedback loop: with only RECORDTYPE EQ to filter on, what stops a subscriber that updates its own record from running forever? In my test, writes the subscriber made with submitFields raised no new subscriber event, on a custom record or a journal entry. But the user event on that custom record did fire, with executionContext reporting EVENTSUBSCRIBER. Your existing user events still run on what a subscriber writes.

What it costs you

It doesn't see approvals. If you've fought a user event that has to catch a sales order being approved, this won't rescue you. I approved one order with the Approve button and another from the Approve Sales Orders page. The user event fired for both, as type approve, with newRecord still reporting Pending Approval. Neither raised a subscriber event, though an orderstatus change made by script between the two approvals was picked up two minutes later. As far as the subscriber is concerned, the approval never happened.

It reads the record as it is now, not as it was. Because the payload is only an ID, the handler loads the record, and four minutes is plenty of time for someone to edit it again. I created a record and edited it a second later. Both runs, the one for the create and the one for the update, read the edited value, and neither could tell which event it was handling. A record created and deleted before the queue drained gave both runs "That record does not exist." Anything that depends on what changed needs its own record of the change.

Failures are quiet. I threw an Error from handle. The record saved normally, the subscriber ran once and was never retried in the next 27 minutes, and the execution log entry read "An unexpected SuiteScript error has occurred." My message was gone. Catch your own errors and write them somewhere you'll look.

You can't see it. There's a hidden script record behind each subscriber, with type EVENTSUBSCRIBER and a deployment marked not deployed, but it isn't in the Scripts list and its record page returns "Page not found." I found its execution log through a scriptexecutionlog search filtered on that script's internal ID.

Deploy order matters. SDF validates the RECORDTYPE value against the account, not the project. A subscriber on a custom record type in the same project fails validation with "Invalid record type script ID" until the record type has been deployed on its own.

What I'd do

Don't move anything that has to happen before the user sees the save. If an afterSubmit sets a value the next screen depends on, it stays a user event. So does anything that has to react to an approval.

Then go through your afterSubmit functions and look for work that can run four minutes late. For each candidate, write the handler for the payload it will actually get: load the record, decide from its current state whether there's work to do, and do it so that running twice does no harm. Wrap the body in a try and log the failure yourself, because NetSuite won't keep your error message for you.

Before any of that, find out whether the account can deploy one at all. Run project:validate on a one-criterion subscriber. If it comes back with "Platform Events are not enabled," start the support case now.

Sources — Oracle NetSuite Help Center

An Event Subscriber tells you where to look

What you actually get

Where it beats a user event

What it costs you

What I'd do

Untangling a pile of afterSubmit logic?