User Event Script Best Practices

General

• Mission-critical business logic implemented using user events should be accompanied by a clean–up scheduled script to account for any unexpected errors or misfires.

• Do not try to execute a user event script from another user event script. Instead, create a module containing the code that is common between the two user event scripts, and use the module in both scripts.

• Make sure that the user event script does not read a sensitive field value.

Context

• Use the type argument and context object to define and limit the scope of your user event logic. See context.UserEventType.

• Use the context argument and context.UserEventType enum to define and limit the scope of your user event logic. See context.UserEventType.

Entry points

• Any operation that depends on the submitted record being committed to the database should happen in an afterSubmit script.

• When updating transaction line items in a beforeSubmit script, ensure that the line item totals net taxes and discounts are equal to the summarytotal, discounttotal, shippingtotal, and taxtotal amounts.

• Assigning many executable functions to one record type is discouraged because this could negatively affect the user experience with that record type. For example, if there are ten beforeLoad scripts that must complete their execution before the record loads into the browser, the time needed to load the record may increase significantly. Be aware of the number of user events scripts used, including bundled user event scripts.

• To set a field on a record or make any changes to a record being submitted, use the beforeSubmit event.

• Perform all post-processing operations of the current record on an afterSubmit event.

Storing values

• If you want to store a value during a beforeLoad operation and then read that value during an afterSubmit operation in the same script, consider using a hidden custom field to store the value. You can add a hidden custom field to the form and store your value during the beforeLoad operation, and you can retrieve the value from the same field during the afterSubmit operation.

Execution contexts

• Use execution context filtering to specify how and when a user event script is executed. Execution contexts provide information about how a script is triggered to execute. For example, a script can be triggered in response to an action in the NetSuite application, or an action occurring in another context, such as a web services integration. You can use execution context filtering to ensure that your scripts are triggered only when necessary. For more information, see Execution Contexts.

Performance

• Limit the amount of script execution in user event scripts (less than five seconds, if possible) since they run often and in-line. You can use the Application Performance Management (APM) SuiteApp to test the performance of your scripts deployed on a specific record type. See Application Performance Management (APM).

Debugging

• When your script stops at the debugger; statement, you can examine your script properties and variables using the debugging tools in your browser. You can also use the debugger; statement in the SuiteScript Debugger to help you debug server scripts. For more information about the SuiteScript Debugger, see SuiteScript Debugger.

Hosted websites

• Activities (user events) on a hosted website can trigger server SuiteScripts. In addition to sales orders, scripts on case records and customer records also execute in response to web activities.