How User Event Scripts are Executed

Important:

User event scripts cannot be executed by other user event scripts or by workflows with a Context of User Event Script. In other words, you cannot chain user event scripts. You can, however, execute a user event script from a call within a scheduled script, a portlet script, or a Suitelet.

User event scripts are executed based on operations defined as beforeLoad, beforeSubmit, and afterSubmit.

Tip:

You can set the order in which user event scripts execute on the Scripted Records page. See The Scripted Records Page.

beforeLoad

The following diagram shows an overview of what occurs during a beforeLoad operation:

User event execution flow on beforeLoad event between client and server.
  1. The client sends a read operation request for record data. This request can be generated from the user interface, SOAP web services, REST web services, CSV import, or server SuiteScript (except other user event scripts).

  2. Upon receiving the request, the application server performs basic permission checks on the client.

  3. The database loads the requested information into the application server for processing. This is where the beforeLoad operation occurs – before the requested data is returned to the client.

  4. The client receives the now validated/processed beforeLoad data.

Note:

Standard records cannot be sourced during a beforeLoad operation. Use the pageInit client script for this purpose. See pageInit(scriptContext).

beforeSubmit and afterSubmit

The following diagram shows an overview of what occurs on beforeSubmit and afterSubmit operations:

User event execution flow on beforeSubmit and afterSubmit events between client and server.
  1. The client performs a write operation by submitting data to the application server. This request can be generated from the user interface, SOAP web services, REST web services, server SuiteScript calls, CSV imports, or XML. The application server:

    1. performs basic permission checks on the client

    2. processes the submitted data and performs specified validation checks during a beforeSubmit operation

    The submitted data has NOT yet been committed to the database.

  2. After the data has been validated, it is committed to the database.

  3. If this (newly committed) data is then called by an afterSubmit operation, the data is taken from the database and is sent to the application server for additional processing. Examples of afterSubmit operations on data that are already committed to the database include, but are not limited to:

    1. sending email notifications (regarding the data that was committed to the database)

    2. creating child records (based on the data that was committed to the database)

    3. assigning tasks to employees (based on data that was committed to the database)

Note:

Asynchronous afterSubmit user events are only supported during webstore checkout.

Related Topics

General Notices