netsuite User Event: Before and After Submit events

Help us to keep this website almost Ad Free! It takes only 10 seconds of your time:
> Step 1: Go view our video on YouTube: EF Core Bulk Insert
> Step 2: And Like the video. BONUS: You can also share it!


  • beforeSubmit(type) // Before Submit, 1.0
  • beforeSubmit(scriptContext) // Before Submit, 2.0
  • afterSubmit(type) // After Submit, 1.0
  • afterSubmit(scriptContext) // After Submit, 2.0


SuiteScript 2.0-
scriptContext.newRecord{N/record.Record} A reference to the record that is being read from the database. We can use it to modify the field values on the record
scriptContext.oldRecord{N/record.Record} A read-only reference to the previous state of the record. We can use it to compare to the new values
scriptContext.type{UserEventType} An enumeration of the type of write action being performed
SuiteScript 1.0-
type{String} The type of write action being performed


beforeSubmit and afterSubmit

These two events are triggered by any database write operation on a record. Any time a user, a script, a CSV import, or a web service request attempts to write a record to the database, the Submit events get fired.

Record actions that trigger both Submit events:

  • Create
  • Edit
  • Delete
  • XEdit (inline edit)
  • Approve
  • Reject
  • Cancel
  • Pack
  • Ship

Record actions that trigger beforeSubmit only:

  • Mark Complete
  • Reassign (support cases)
  • Edit Forecast

Record actions that trigger afterSubmit only:

  • Dropship
  • Special Order
  • Order Items
  • Pay Bills

Typical Use Cases for beforeSubmit

  • Validate record before it is committed to database
  • Permission and restriction checks
  • Last-minute changes before database commit
  • Pull updates from external systems

Typical Use Cases for afterSubmit

  • Email notification of record changes
  • Browser redirection
  • Create/update dependent records
  • Push changes to external systems

User Events do not chain

Code written in User Events will not trigger any User Events on other records. For example, modifying the associated Customer record from the beforeSubmit of a Sales Order record will not trigger the Customer record's submit events.

NetSuite does this to avoid User Events triggering each other in an infinite loop. If you do need User Events to fire in a chained sequence, other script types (e.g. RESTlets, Suitelets, Scheduled Scripts) will need to be injected in between the events.

Event Handlers return void

The return type of the Submit event handlers is void. Any data returned from our event handler has no effect on the system. We do not need to return anything from our handler function as we cannot actually do anything with its returned value.


Be very cautious when comparing values between old and new records. Empty fields from the old record are returned as null, while empty fields from the new record are returned as an empty String. This means you cannot simply compare the old with the new, or you will get false positives. Any logic you write must handle the case where one is null and one is an empty String appropriately.

Got any netsuite Question?