Understanding NetSuite Scripts: A Guide to Customization

BeforeSubmit, Client Script, FieldChanged—if you’ve worked with NetSuite customizations, you may have come across these terms in our documentation or discussions. While they are part of our daily work at FoodQloud, we understand they might not be immediately familiar to everyone.

In this blog post, we’ll break down these concepts, explaining their purpose and providing real-world examples of how they contribute to NetSuite’s customization capabilities. Whether you’re new to scripting or looking for a deeper understanding, this guide will help you navigate the fundamentals.

Tailor NetSuite to Your Needs

One of NetSuite’s greatest strengths is its flexibility—it can be tailored to fit your business processes and industry-specific needs. However, to ensure long-term efficiency and scalability, customizations must follow best practices. That’s where our expertise comes in.

As a trusted NetSuite partner, FoodQloud helps ensure that every customization is designed with scalability, maintainability, and business value in mind. But before diving into custom development, the first crucial step is determining which script type to use and when it should be triggered.

Script Types in NetSuite

Each script has its own type, defining where and how it operates. The most commonly used types are:

• User Event Script – Executes in the background when records are created, updated, or deleted.

• Client Script – Runs in the user’s web browser during screen interactions.

• Suitelet – A custom UI page that users can interact with.

• Back-end Scripts – Generic term for scripts running in the background without user interaction, such as RESTlets, Scheduled Scripts, and Map/Reduce Scripts.

After selecting the script type, the next step is defining the script entry point, which determines when and how the script executes.

Key NetSuite Script Types

User Event Script

User Event Scripts execute server-side and are triggered when users perform specific actions on records (view, create, update, copy, delete, submit). They also execute through NetSuite’s automated processes, such as mass transaction creation.

Frequently Used User Event Script Entry Points:

• beforeLoad – Runs before a record is loaded, useful for pre-populating values or adding custom UI elements like buttons.

• beforeSubmit – Runs before a record is saved to the database, useful for backend calculations that don’t need to be visible to users.

• afterSubmit – Runs after a record is committed to the database, typically for processes that depend on a successfully saved record, such as updating related records.

A Client Script

Client Scripts execute in the user’s web browser and are triggered during record interactions. They are useful for enhancing user experience without directly impacting stored data.

Frequently Used Client Script Entry Points:

• pageInit – Runs when a form loads, useful for modifying fields before the user sees them.

• fieldChanged – Runs when a user changes a field value, useful for validation or updating related fields.

• postSourcing – Runs when data is automatically sourced, such as when selecting a customer on a Sales Order.

• lineInit – Runs when an existing sublist line is selected, similar to pageInit but for sublists.

• validateLine – Runs when a sublist line is added or edited, useful for enforcing validation rules.

• saveRecord – Runs before a record is saved, useful for final validation checks before data is committed.

Understanding Record Context

Therecord context defines how a user is interacting with a record. Common record contexts include:

• View – When a record is being viewed.

• Create – When a new record is being created.

• Edit – When an existing record is modified.

• Delete – When a record is removed.

• Copy – When a record is duplicated.

While record context is not mandatory, it helps improve performance by ensuring that scripts only execute when necessary.

Example Scenario

A business may require that every Sales Order has a PO# before it can be saved. To meet this requirement:

• A User Event Script (script type) ensures that Sales Orders created through non-UI methods (context type), such as CSV imports or system integrations (entry point), also fail if the PO# is missing.

• A Client Script (script type) is used to validate the PO# field when an employee enters a Sales Order (entry point) and attempts to save (context type). If the field is empty, they receive an error message.

By combining Script Type, Script Entry Point, and Record Context, we establish the foundation for effective customization.

Conclusion

To summarize the topics we have covered today and to give you a better perspective of the script types and their entry points, this is the flowchart of the entire process;

Stay tuned for our next blog post, where we’ll explore more advanced script types!

Story by: Stan van den Oever