Leveraging Script Management for a More Responsive NetSuite Account

Business Problem: Custom scripts are a powerful and widely used feature of NetSuite. However, if they aren’t tightly managed, they can easily get out of hand. Poorly managed scripts can slow load times, interfere with each other or confuse staff and developers. One of the many goals of FLODocs is to help NetSuite customers get a handle on their scripts. Ideally, we want as little scripting running as possible to achieve our business purposes. This guide will walk you through the key steps to getting your account running as smoothly as possible.

Background: There are numerous types of scripts in NetSuite. The ones we are most concerned about are user event scripts and scheduled scripts since these execute the most frequently. User event scripts are triggered when a certain user action occurs such as opening or saving a record. Scheduled scripts are triggered either at a certain time or when scheduled by another script. The important difference is that user event scripts may need to complete before NetSuite can display a record, save changes or return the update record.

FLODocs Script Management gives Administrators new tools to identify and weed out key issues. Prior to using Script Management it is necessary to have a license for the module and to have completed the Script Management setup steps in the FLODocs User Guide. A few days later you will be able to look at each of the following problems:

1. Scripts running too often:

If you process X orders a day but have 10X or 100X script executions related to those orders, that is a problem. Use the Critical Scripts Analysis Search to identify any your scripts are executing disproportionately to your business activities. You can easily see the date the script last run, the number of times it runs per day and the historical highs and lows.

EXAMPLE: A common scenario is:

  1. Saving record A triggers script B which updates record C
  2. Saving record C triggers script D which updates record A which triggers script B again etc.

EXAMPLE : A script that updates the same field over and over each time the record is saved.

This will show a consistent average run time but a high number of incidents. To stop this, consider conditions that end the script if certain fields have not changed. Alternatively, move the script to a workflow that is only triggered if such fields change.

In the most extreme examples one script will actually call the other script and vice versa. In each case, you can then use the FLODocs documentation to identify any scripts that may be directly or indirectly triggering your script.

2. Scripts running in the multiple departments or subsidiaries:

User event and client scripts are usually only needed at a particular stage of a business process and should only be triggered by specific types of users. Script Management tracks who is triggering the script. You can therefore identify which departments and subsidiaries are being affected.

EXAMPLE: it is rarely necessary for a script that calculates Gross Profit on sales records (Estimate, Sales Order, Invoice) to be run by anyone other than the sales team.

You can quickly search for any scripts that touch the Sales record that are being triggered by people outside of the sales team. This can usually be fixed on the deployment.

3. Scripts unintentionally triggered by the Shopping Cart, Forms, Web Services and other Integrations:

User event scripts can significantly slow submission times for NetSuite shopping carts, forms, integrations, web service requests and other integrations. FLODocs tracks all scripts that are triggered by external users such as customers and can track requests made through web services users (if a dedicated user is used). These scripts should be reviewed to determine if they need to execute immediately in these contexts. In some cases, they may not be needed at all in this context. Others can be deferred to be processed later as a scheduled workflow or script.

4. Scripts unintentionally triggered by other scripts:

User event scripts triggered by scheduled scripts, updates or workflows can also cause significant load and slow these scheduled processes. FLODocs tracks scripts triggered by the “system” representing a scheduled process with no user so that these can be systematically optimized. Changing context to only execute for relevant roles or only for employees can in many cases significantly improve execution times.

5. Scripts running against empty fields:

FLODocs tracks the date last used for each field which is very useful for cleaning up fields. However, a bigger performance concern is that there could be scripts or workflows running against these unused fields. With some exceptions, a script or workflow that is running but is reading or writing to a field that hasn’t had data in it or system notes on it for months is probably putting an unnecessary load on your account. In some cases, you will realize that the script is no longer necessary and can be turned off. In others, a project should be created to optimize the script.

6. Scripts with suspect API calls:

It’s not usually the code itself that slows down an account, it’s the retrieval and writing of data to the database through searches, record loads and posting activity (record saves and field submits). There are best practices for what to do and what not to do with certain types of fields. These rules can be broken but they normally indicate a situation you need to pay attention to:

  • nlapiLoadRecord or nlapiSubmitField in a client or user event script - particularly if the record being loaded is the record that triggers the script. NS recommends using nlapiLookupField and nlapiSubmitField to update records whenever possible.
  • nlapiSearchRecord with no corresponding search - this can make it very difficult to test whether the search is efficient. This was considered a best practice in the past in order to protect search criteria needed by scripts. However, FLODocs can identify and warn of changes to searches that have script dependencies.
  • nlapiSearchRecord in a user-event script - Generally, there shouldn’t be searches in user-event scripts unless absolutely necessary since this can delay the interface significantly. You should check these scripts to ensure that they have very tight execution criteria to ensure they only execute when they are useful. In many cases, it is preferable to pre-process and store the related data (eg a related record) and use nlapiLookupField to get the data the script needs. If a search is needed the description should explain why.
  • Old searches leveraged by Scripts - You should review your scripted searches to ensure they are as optimized as possible. A common situation is that the search a script uses was developed at the start of a business process when there were no records. These searches might be too broad in scope or may not be optimized to retrieve data efficiently. They should be reviewed and optimized. In some cases, some thought should be given to whether the required relationship should be stored differently to avoid searching which can be time-consuming.
  • Deployed scripts in Debug Logging Mode: Logging debug messages requires writing records to the database. While this process is optimized, our testing shows that it takes at least 150ms per entry. Therefore, it is important to set all deployed scripts to Error or preferably Audit. Audit log level will enable FLODocs to track when and how often the script is executing (see the FLODocs Script Management setup) without appreciably slowing the script.

If you need help managing cleanup, FLODocs would be happy to work with your existing consultants or refer you to consultants from NetSuite or independent solution providers who can assist you.