23 A Brief Overview of SuiteScript

NetSuite is a very large, complex ERP system that allows developers a massive level of customization through “SuiteScript”.

NetSuite Records, Events, and Script Types

NetSuite organizes its data into elements called Records. As these Records are created, manipulated, and updated by various sources, NetSuite fires Events. Some of those Events might be triggered by a User interacting with a Record, by a specific time of day, by a Script modifying a Record, or by an external system sending a request for data. There are dozens of Events and potential triggers for those Events. As users, scripts, and external systems are all working within NetSuite, these Events are constantly getting triggered.

Our primary job as NetSuite Developers is to identify which Events we need to respond to, then creating the appropriate Script Type that is triggered by those Events. NetSuite provides us with ten different Script Types to choose from, and each is triggered by a unique set of Events:

  • Client Script
  • User Event
  • Suitelet
  • Portlet
  • RESTlet
  • Scheduled
  • Map/Reduce
  • Mass Update
  • Workflow Action
  • Bundle Installation

NetSuite’s Help documentation is the best resource to learn more about these Script Types and which Events will trigger them. I highly recommend you study there for more details. To be a fully competent SuiteScript developer, you should absolutely know off the top of your head what every single Script Type is, and which Events it will respond to.

SuiteScript Source Code

Once we’ve selected the right Script Type(s) for our project, we can start creating the source code for each one. When we write scripts for NetSuite, we write completely standard JavaScript, and we have access to the SuiteScript library API as well to work with NetSuite features.

NetSuite Scripts are based entirely on JavaScript structured with the AMD Module style. Check out my video on SuiteScript Modules for greater detail on how these modules are structured.

As an example, let’s select a Client Script that responds to the user loading a Record in the UI.

The first step to creating our module is to open a blank text document and add some JSDoc that indicates what Script Type we are creating.

This tells NetSuite what Script Type we’re creating, what version of SuiteScript we’re using, and the privacy settings of our module.

Next, we need to define our module and any dependencies it has. We do this using the AMD Module’s define method.

We don’t have any dependencies, so we can jump right into creating our Script. We want our script to display a message when the user loads a Record in the UI, so we need to write a function to do that.

Next, we use the output of our Module to connect our function to the appropriate Event. The Event that gets fired when the page loads is called pageInit:

Whenever the pageInit Event is triggered, NetSuite will automatically invoke our showMessage function.

We save our file as a JavaScript file (with a .js extension), and that is it for our source code.

The next step is to upload our source file to the NetSuite File Cabinet.

Script Records

We navigate to Customization > Scripting > Scripts > New and select the source file from our hard drive. NetSuite will use the JSDoc we created at the top of the file to instantiate a new Script Record. We give our Script a name and a readable ID and save it.

Once it saves, we can see that NetSuite automatically recognizes the appropriate Script Type, API Version, and Event triggers based on what we defined inside our module.

Script Deployments

Once that is complete, we have successfully connected our source code to an Event in NetSuite, but we have not told it which Record Types or Users should be able to trigger this Script. We do that through a Script Deployment record.

We create a Deployment using the Deploy Script button on our Script Record. Once again, we choose an appropriate name and a readable ID. Next we set the Applies To to define which Record Types will trigger our Script. Lastly, on the Audience tab, we select who should actually trigger this Script. We can select any number of specific Users, Roles, Groups, and more. If our Script should be triggered by everyone, then we simply select “All Roles”, which is the most common setting.

All that’s left is to demonstrate that our Script works. In the UI, we can navigate to a Record with the same Record Type as our Deployment, then click Edit, and we should see our alert message pop up.

You can find all the code for this example project in my Learn SuiteScript project repository:

Join Effective SuiteScript for weekly content to help you learn NetSuite development