About Salto: Salto helps you and your team deploy, track, and manage your NetSuite customizations effortlessly. Learn more here.

‍

It is often tempting to jump right in and solve for a specific NetSuite customization challenge or deliver a specific project without giving thought to the broader impact on the NetSuite environment as a whole.

In fact, most NetSuite resources are focused on the support for NetSuite customization, but place little emphasis on the impact to other areas of the system and those that interact with it. We will explore some of the key things NetSuite developers and administrators overlook when customizing NetSuite.

‍

Performance

NetSuite system performance is directly impacted by customizations and custom development made in the environment. Make sure you invest the time in advance to evaluate the correct development approach, e.g. user event script vs scheduled script, scheduled script vs map/reduce script. I discuss this topic in greater detail here.

Consider the following: a Salesforce to NetSuite integration that involves the creation of sales order records in NetSuite, and you want to perform an update to the NetSuite record once the sales order record has been created. One way to achieve this would be via user event script. This would allow you to make the required updates to the sales order record on creation. The downside to this approach is that the script will execute on every sales order created via this integration and therefore impact the performance of the sales order creation process, in turn slowing down the ability to integrate records with optimal efficiency. Instead, consider whether the record must be updated immediately after creation in NetSuite. If so, should those changes be captured upstream in Salesforce or ETL processes? Alternatively, if the records do not need to be immediately updated after creation, a scheduled script could be created to perform the required updates. If the volume of sales orders created via this integration is significant, you may want to consider a more efficient process by creating a map/reduce script.

Another thing to consider is the ease with which custom fields can be added to NetSuite. It would be easy to add several custom transaction line level fields to the environment, but adding custom line level fields impacts performance, as each field is available on every line vs a single value at the transaction header. In addition, the more line level fields are added, the more difficult it becomes for the user to navigate the form effectively.

Leverage your NetSuite sandbox or development environment to test the impact each customization has on performance prior to committing the changes to production. 

Salto Suite Tip: Consider leveraging a tool, such as Salto, that will seamlessly manage the migration process of your NetSuite customizations. Doing so reduces time and risk, ultimately freeing up NetSuite administrators to focus on more valuable tasks.

‍

Flexibility

Solving the problem for the current state is always a win, but we need to acknowledge that business requirements evolve over time, now more than ever. As such, solutions need to be implemented with both flexibility and scalability in mind. A great example of this is referencing the results of a NetSuite saved search as a script parameter vs hard coding in the script itself. This allows for the flexibility to replace or update the saved search referenced in the script parameter in the future to meet new business requirements.

Another consideration is to build solutions that can be repurposed for future use—for example, implementing a custom mass update script in a way that allows it to be easily applied to other records in the future. While the script might not be required today for those other records, NetSuite developers and administrators add value by being able to quickly turn around such a request in the future because the foundation is already there.

For those operating in a NetSuite OneWorld environment, think about the ability to add subsidiaries to a specific NetSuite workflow or NetSuite Suitescript. If your company expands into a new region, how easy or difficult will it be to update existing NetSuite customizations to accommodate any new subsidiaries created? Ideally, it would be as simple as adding any new subsidiary to the existing deployment audience. If it is not that simple, think about how you can scale the solution as the company grows, e.g. consider the use of a new custom record type that can be referenced and new custom records for each new subsidiary as necessary.

‍

User Interface

The NetSuite user interface is often overlooked when it comes to customizing NetSuite, which is unfortunate as this is what the NetSuite end users use daily. Of course, we want to deliver an optimized solution to meet business requirements, but that does not need to come at the expense of the end users’ interactions with the system. 

Think about all of the custom forms in your NetSuite environment today. How many have been fully customized to include fields that end users are required to populate and/or reference? Have they also been included under the appropriate headings and subtabs? This exercise will always take a concerted effort, or else you run the risk of cluttering up the user interface and ultimately slowing down your end users.

Consider broadening the use of custom forms to align with specific user roles or specific subsidiaries. Often, different roles and subsidiaries will have slightly different requirements when interacting with a given record. Perhaps some fields should be considered mandatory for role A, but optional for role B. Likewise, for subsidiary access to localization fields, subsidiary A may not need to see a specific set of fields only relevant to subsidiary B. Users’ roles can then be configured accordingly to have access to only pertinent custom forms.

If you are looking for great control over the look and feel of the NetSuite interface, you should investigate the use of Suitelets. These are a type of NetSuite Suitescript that allow NetSuite developers to build customized pages that users interact with. They will generally have the look and feel of the NetSuite application, but have greater flexibility.

‍

‍

User Access

User access is another area that is often missed when customizing NetSuite. It is important that user access be restricted and the ‘principle of least privilege’ be applied. Thinking about this in advance will ensure both unit testing and user acceptance testing are performed with the appropriate NetSuite roles. There is a habit to perform testing with the Administrator role, which is fine for the initial review, but if you do not extend your testing to the specific NetSuite roles that will be working with the customization in the future, you will almost certainly run into challenges during user acceptance testing and/or post go-live.

Access to custom records can be driven from the customer record itself or from user role permissions. Both have merit. The key is to keep this consistent across the NetSuite environment. If there was a bias, it would be towards managing within the user roles themselves, so that all user access is managed within the role permissions themselves (as hopefully you are avoiding the use of global permissions).

‍

‍

‍

‍

‍

Documentation

For more mature NetSuite environments, NetSuite developers and administrators often inherit some amount of technical debt from prior team members that have customized the NetSuite environment they now find themselves managing. Without proper documentation of the NetSuite customization performed and how it was configured, it can be a challenge to get up to speed.

One option would be to build out a library for NetSuite development, with corresponding change management tickets (if applicable) and good descriptions for each. This would then provide a single source of truth for NetSuite customization performed within a specific environment and allow newer team members to get up to speed much more quickly than by exploring the environment themselves and asking lots of questions.

Populating the “Description” field on customized NetSuite records can also help NetSuite developers and administrators quickly understand the purpose of each record. Further, populating the “Help” field on custom fields can help NetSuite end users better understand the purpose for each field. You should also consider populating hyperlinks in these field values that point to an external library/source of truth for all NetSuite customization.

‍

‍

‍

Final thoughts

NetSuite is a leader in the cloud ERP space, in part, because of it’s ability to adapt to each of its customer’s requirements. This freedom to customize the system comes as the cost of needing to monitor and maintain it. If not managed appropriately, customizations can result in poor system performance and poor user experience. This becomes more and more challenging to unwind as new development is layered on top of the existing infrastructure. Instead, be sure to consider the 5 points above for all future NetSuite customization, so you do not need to unwind in the future. You might want to consider creating a mini checklist for things to consider for new NetSuite customization and the points raised here would be a great starting point.

If you found this content useful, please share. If you have any suggestions for future NetSuite-focused content, please submit them to arik.marmorstein@salto.io.