SuiteScript 2.x Script Types

SuiteScript 2.x offers several script types each with their own entry points as described in the following table.

Script Type	Description	Where They Execute
SuiteScript 2.x Bundle Installation Script Type	Bundle installation scripts are specialized server scripts that perform processes in target accounts as part of a bundle installation, update, or uninstallation. These processes include setup, configuration, and data management tasks that would otherwise have to be completed by account administrators. Entry points: afterInstall(params) - defines the function that executes after a bundle is installed for the first time in a target account. afterUpdate(params) – defines the function that executes after a bundle in a target account is updated. beforeInstall(params) - defines the function that executes before a bundle is installed for the first time in a target account. beforeUninstall(params) - defines the function that executes before a bundle is uninstalled from a target account. beforeUpdate(params) – defines the function that executes before a bundle in a target account is updated.	On the server
SuiteScript 2.x Client Script Type	Client scripts are scripts that are executed by predefined event triggers in the client browser. They run on individual forms, can be deployed globally, and are applied to entity and transaction record types. They can validate user-entered data and auto-populate fields or sublists at various form events. Global client scripts enable centralized management of scripts that can be applied to an entire record type. Entry points: fieldChanged(scriptContext) – defines the function that executes when a field is changed by a user or client call. lineInit(scriptContext) – defines the function that executes when an existing line is selected. localizationContextEnter(scriptContext) – defines the function that executes when the record enters the localization context that is specified on the script deployment record. localizationContextExit(scriptContext) – defines the function that executes when the record exits the localization context. pageInit(scriptContext) – defines the function that executes when the page completes loading or when the form is reset. postSourcing(scriptContext) – defines the function that executes when a field that sources information from another field is modified. Executes on transaction forms only. saveRecord(scriptContext) – defines the function that executes when a record is saved (that is, after the Submit button is pressed but before the form is submitted). sublistChanged(scriptContext) – defines the function that executes after a sublist has been inserted, removed, or edited. validateDelete(scriptContext) – defines the function that executes when an existing line in an edit sublist is deleted. validateField(scriptContext) – defines the function that executes when a field is changed by a user or client side call. validateInsert(scriptContext) – defines the function that executes when a sublist line is inserted into an edit sublist. validateLine(scriptContext) – defines the function that executes before a line is added to an inline editor sublist or editor sublist.	On the client’s browser
SuiteScript 2.x Map/Reduce Script Type	The map/reduce script type is designed for scripts that need to handle large amounts of data. They provide a structured framework for processing a large number of records or a large amount of data and are best suited for situations where the data can be divided into small, independent parts. Entry points: getInputData(inputContext) – defines the function that marks the beginning of the map/reduce script execution. This entry point invokes the input stage which is where input data is generated. map(mapContext) – defines the function that invokes the map stage where input data is parsed into key-value pairs. reduce(reduceContext) – defines the function that invokes the reduce stage where processing can occur for each key-value pair. summarize(summaryContext) – defines the function that invokes the summarize stage where processed data is summarized.	On the server
SuiteScript 2.x Mass Update Script Type	Mass update scripts allows you to programmatically perform custom mass updates to update fields that are not available through general mass updates. These scripts can run complex calculations across many records. Entry points: each(params) – defines the function that iterates through all applicable records allowing you to add logic to each record.	On the server
SuiteScript 2.x Portlet Script Type	Portlet scripts are used to create custom dashboard portlets. For example, you can use the portlet script type to create a portlet that is populated on-the-fly with company messages based on data within the system. Entry points: render(params) – defines the function that executes when the Portlet script is triggered.	On the server, but rendered on the client’s browser
SuiteScript 2.x RESTlet Script Type	RESTlets can be used to define custom RESTful integrations to NetSuite. You can make a RESTlet available for other applications to call, either from an external application or from within NetSuite. When an application or another script calls a RESTlet, the RESTlet script executes and, in some cases, returns a value to the calling application. Entry points: delete – defines the function that executes when a DELETE request is sent to a RESTlet. An HTTP response body is returned. get – defines the function that executes when a GET request is sent to a RESTlet. An HTTP response body is returned. post – defines the function that executes when a PUT request is sent to a RESTlet. An HTTP response body is returned. put – defines the function that executes when a POST request is sent to a RESTlet. An HTTP response body is returned.	On the server
SuiteScript 2.x Scheduled Script Type	Scheduled scripts are server scripts that are executed (processed) with SuiteCloud Processors. You can deploy scheduled scripts so they are submitted for processing at a future time, or at future times on a recurring basis. You can also submit scheduled scripts on demand from the deployment record or from another script with the N/task Module. Entry points: execute – defines the function that executes when the scheduled script is triggered.	On the server
SuiteScript 2.x Suitelet Script Type	Suitelets allow you to build custom NetSuite pages and backend logic. They are server scripts that operate in a request-response model, and are invoked by HTTP GET or POST requests to system generated URLs. Suitelets enable the creation of dynamic web content and build NetSuite-looking pages, and they can be used to implement custom front and backends. Entry points: onRequest(params) – defines the function that executes when the Suitelet is triggered.	On the server
SuiteScript 2.x User Event Script Type	User event scripts are executed when you perform certain actions on records, such as create, load, update, copy, delete, or submit. These scripts customize the workflow and association between your NetSuite entry forms. These scripts can also be used for additional processing before records are entered or for validating entries based on other data in the system. Entry points: afterSubmit(context) – defines the function that executes immediately after a write operation on a record. beforeLoad(context) – defines the function that executes whenever a read operation occurs on a record, and prior to returning the record or page. beforeSubmit(context) – defines the function that executes prior to any write operation on the record.	On the server
SuiteScript 2.x Workflow Action Script Type	Workflow action scripts allow you to create custom Workflow Actions that are defined on a record in a workflow. Entry points: onAction(scriptContext) – defines a Workflow Action script trigger point.	On the server
SuiteScript 2.x SDF Installation Script Type	SDF installation scripts are used to perform tasks during deployment of a SuiteApp from SuiteCloud Development Framework (SDF) to your target account. They are automatically executed when a SuiteApp project is deployed. Entry points: run(scriptContext) – defines what is executed when the script is specified to be run by the SDF deployment (in the deploy.xml file of an SDF project).	On SuiteApp project deployment

Best Practices

• Always thoroughly test your code before using it on your live NetSuite data.

• Type all record, field, sublist, tab, and subtab IDs in lowercase in your SuiteScript code.

• Prefix all custom script IDs and deployment IDs with an underscore (_).

• Do not hard-code any passwords in scripts. The password and password2 fields are supported for scripting.

• If the same code is used across multiple forms, ensure that you test any changes in the code for each form that the code is associated with.

• Include proper error handling sequences in your script wherever data may be inconsistent, not available, or invalid for certain functions. For example, if your script requires a field value to validate another, ensure that the field value is available.

• Organize your code into reusable chunks. Many functions can be used in a variety of forms. Any reusable functions should be stored in a common library file and then called into specific event functions for the required forms as needed.

• Place all custom code and markup, including third party libraries, in your own namespace.

  Important:

  Custom code must not be used to access the NetSuite DOM. Developers must use SuiteScript APIs to access NetSuite UI components.

• Use the built in Library functions whenever possible for reading/writing Date/Currency fields and for querying XML documents

• During script development, break your scripts into components, load them individually, and then test each one — inactivating all but the one you are testing when multiple components are tied to a single user event.

• When working with script type events, your function name should correspond with the event. For example, a pageInit event can be named PageInit or formAPageInit.

• Since name values can change, ensure that you use static ID values in your API calls where applicable.

• Although you can use any desired naming conventions for functions within your code, you should use custom namespaces or unique prefixes for all your function names.

• Thoroughly comment your code. This practice helps with debugging and development and assists NetSuite Customer Support in locating problems if necessary. However, not the inline comments are not allowed within an object.

• You must use the runtime.getCurrentScript() function in the runtime module to reference script parameters. For example, use the following code to obtain the value of a script parameter named custscript_case_field:

                define(['N/runtime'], function(runtime) {
      function pageInit(context) {
          var strField = runtime.getCurrentScript().getParameter('SCRIPT', 'custscript_case_field');
          ...
      }); 
  
              

• Make sure that your script does not take a long time to execute. A script may execute for a long time if any or all of the following occur:

  • The script performs a large number of record operations without going over the usage limit.

  • The script causes a large number of user event scripts or workflows to execute.

  • The script performs database searches or updates that collectively take a long time to finish

  Each server script type or application has a time limit for execution. This limit is not fixed and depends on the script type or application. If a single execution of a server script or application takes longer than the time limit for that script type or application, a SSS_TIME_LIMIT_EXCEEDED error is thrown. This error can also be thrown from a script that is executed by another script (for example, from a user event script that is executed by a scheduled script).

You can use SuiteScript Analysis to learn about when the script was installed and how it performed in the past. For more information, see Analyzing Scripts.

Related Topics

SuiteScript 2.x

SuiteScript 2.x API Introduction

SuiteScript 2.1

SuiteScript 2.x Analytic APIs

SuiteScript 2.x Record Actions and Macros

SuiteScript 2.x JSDoc Validation

SuiteScript 2.x Entry Point Script Creation and Deployment

SuiteScript 2.x Custom Modules

SuiteScript 2.x Scripting Records and Subrecords

SuiteScript 2.x Custom Pages

Transitioning from SuiteScript 1.0 to SuiteScript 2.x

General Notices