netsuite User Event: Before and After Submit events
Syntax
- beforeSubmit(type) // Before Submit, 1.0
- beforeSubmit(scriptContext) // Before Submit, 2.0
- afterSubmit(type) // After Submit, 1.0
- afterSubmit(scriptContext) // After Submit, 2.0
Parameters
| Parameter | Details |
|---|---|
| SuiteScript 2.0 | - |
scriptContext | {Object} |
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 |
Remarks
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.
!! CAUTION !!
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.
