Common Pitfalls in NetSuite SuiteScript Development and How to Avoid Them
This blog post will explore some of the common mistakes that a developer encounters during custom development in NetSuite.
Neglecting field validation considerations
When dealing with custom fields within NetSuite, it’s crucial to take into account field validation. Consider the desired end-user behavior you aim to encourage. If your goal is to ensure users consistently fill in a field before saving the record, designate the field as mandatory. Also, be careful regarding the field type and what value you are trying to set on that field. It is advisable to know each field and its nature that is directly or indirectly involved in the script.
Disregarding user access considerations
Before initiating any new NetSuite customization, it is important to understand which user roles are necessary for executing the process. Subsequently, it is essential to ensure that proper access is provided for any new objects and/or records integrated into the new solution. Additionally, update user role permissions when introducing new record types.
This situation frequently arises when a solution has undergone thorough testing and deployment to production, only for users to raise concerns about their inability to access required records. In more serious cases, there may be instances where users who should not have access to certain records gain unauthorized entry. Always consider user access carefully for each customization.
Neglecting considerations for system performance
Creating an impressive SuiteScript solution that fulfills all your end user’s needs is great, however, if it leads to a substantial delay in loading or saving related scripted records, it might adversely impact efficiency rather than contributing to it.
It is advisable to do a proper full load testing to ensure that the script does not run out of any governance or time out issue. Also testing with multiple records with different scenarios helps to ensure the performance of the script. Utilizing APM is also advised.
Unintentionally creating interdependencies.
For most NetSuite admins and developers, the customization process begins in a sandbox or development environment. These customizations typically don’t occur in isolation; in fact, it’s common for multiple planned customizations to be simultaneously developed, often by different individuals.
Without proper oversight, these separate customizations may inadvertently impact each other. For instance, if one developer is creating a SuiteScript solution to enhance functionality in the sales order transaction record, while an administrator is concurrently working on refining sales order transaction forms, there’s a potential for unintentional dependencies between the two customizations.
This doesn’t imply that you should only work on one solution at a time in a sandbox or development environment, as that would significantly slow down the process. Instead, ensure that there is a central team or system architect who is aware of all ongoing customizations in the NetSuite environment. This individual can assess the risk of creating dependencies. If the risk is substantial, it may be prudent to run the development in parallel and test both solutions simultaneously. This approach allows any conflicts introduced to be identified and addressed during end user testing rather than discovering them in the production environment. If the risk is deemed negligible, development can proceed independently.
Conducting tests solely with the Administrator role
NetSuite developers frequently come across a situation where they thoroughly test a process with the Administrator role, but overlook testing it from the perspective of an end user. While the unit testing may appear successful, user acceptance testing often encounters immediate issues because the user roles lack the necessary permissions to engage with the new customization. This scenario is particularly common when dealing with new NetSuite custom records.
To avoid this, it’s essential to document the requirements for a NetSuite customization, explicitly specifying the end user roles that need access to interact with the customization and the level of access required (e.g., view access versus edit access).
In both unit testing and user acceptance testing documentation, include a column to confirm the NetSuite user role responsible for testing each scenario. This practice helps minimize the risk of developing solutions without considering the end user roles that will be using the solution in the Production environment.
Bundling script components incorrectly
When bundling in NetSuite, it’s essential for developers to compare the Sandbox and Production environments. This ensures they know which components are moving to Production and their impact there. If a component is already in Production, including it in the bundle may override existing values. For instance, if a field is in the bundle and already exists in Production, improper installation might overwrite the existing value. Caution is also needed when including saved searches in bundles, as unnecessary fields may be included and moved to Production. To prevent such issues, NetSuite developers should be careful during bundling and installation.
