SuiteScript allows developers to customize NetSuite in a number of ways and provides the ability to fulfill complex requirements of customers that cannot be met by out-of-the-box NetSuite. With such a powerful tool in hand, it is important for developers to follow certain best practices while performing customizations so as to not impact the NetSuite account they are working on.
The first and foremost point to keep in mind in the governance limit of each script type. There are 10 different script types offered by NetSuite which allow developers to perform customizations on both the client side and server side, and each of them has a pre-defined governance limit. Exceeding these limits will cause exceptions and “Usage Limit Exceeded” errors. This is a very basic principle that all the developers need to be aware of, but deeper analysis of governance limits is beyond the scope of this article.
This blog will delve into how many scripts of each script type can be deployed on a record/transaction, and what are the recommendations provided by NetSuite around the same. This will be helpful for NetSuite accounts that have a high number of scripts and customizations in place, so that scripts can be tuned and adjusted accordingly.
Client Scripts and User Event Scripts:
Client scripts are used to handle the client-side functionality while all the other remaining scripts are server-side scripts and are used to handle the backend functionality.
Client script and User event script types get triggered based on the user’s actions performed on the UI. Behind the scenes there may be some server side scripts which could be triggered indirectly by the user event script, however, prominently only these two script-types are executed by the user’s actions on a record in NetSuite.
As per NetSuite developer documentation there is no limit to the number of user event scripts that can be executed on a particular record-type. For example – We can deploy 10 beforeLoad, 9 beforeSubmit and 15 afterSubmit executing functions on a record which supports that specific script type, but NetSuite recommends not more than 10 scripts of the same trigger type.
Similarly, in the case of client scripts, there is a limit of 10 scripts per record. NetSuite will execute only the first 10 deployed scripts by taking into account the performance.
Developers who include scripts in their bundles should also be aware of the number of user events scripts that might have already been deployed to the different record types in the target NetSuite account, and work with the client closely to determine a strategy and design that will work for their NetSuite account.
For example – if 8 beforeSubmit user event scripts are already deployed to the Sales Order record in the client NetSuite account, and your bundle includes another 7 beforeSubmit user event scripts on the same record type, the total number is 15 beforeSubmit scripts. All these scripts will run every time a user clicks Save on the Sales Order record. With all these scripts running on save, the time it takes for the record to save may be significantly increased, again, negatively affecting user experience.
Deploying a higher number of client scripts may create a delay in manipulating data on the record when the user is editing the record. If the number of client scripts that are deployed on a record exceeds the count of ten, the most recent scripts which are deployed will be prioritized lower on the scripted records page, and may or may not be executed.
Tvarana’s Scripting Best Practices:
● Maintain a control over the number of scripts deployed on a particular record for a specific event, as it can impact performance
● Avoid deploying more than 10 scripts of the same event type as this could negatively affect user experience with that record type
● Apply limits to script execution in user event scripts (less than 5 seconds, if possible), since they run often and run in-line
● Use the scripting record page to change the order of execution of scripts, so that high priority scripts on the top will execute first
● View the overall execution time of each record instance, as well as the execution time of each individual script using APM
● Avoid performing operations like updating records through client scripts, which can affect page performance
