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

‍

Introduction

NetSuite system performance is not something we normally talk about until there is a problem. And that is a problem. You have this high functioning, fully customizable platform at your disposal and yet system performance (which directly impacts the end users you support) is an afterthought, if that. 

In this blog post, we are going to explore some of the common mistakes made when thinking about NetSuite performance. You will see that some mistakes stem from an aversion (whether intentional or not) to focusing on system performance, whereas other mistakes are the result of not having the right solution design. Combining the two is a recipe for disaster when it comes to system performance, so let’s take a deeper look at these common mistakes before wrapping up with 10 best practices for managing NetSuite performance going forward.

‍

‍

Mistake 1 - Assuming NetSuite is the issue

When a particular record type or function starts to take longer to load, edit, or save, it is easy to point the finger at NetSuite for the change in performance—when in fact the vast majority of system performance challenges are the result of internal customization that was completed without proper thought given to the system impact of such a change.

These issues are more prevalent in larger, more complex SuiteScripts and Workflows that have been overengineered to meet very specific business requirements. It is important to strike the right balance between finding the perfect solution and its impact to system performance. Equally important is to be transparent with your end users that perhaps 95% of the requirements will have a negligible impact to system performance but the remaining 5% is highly complex and is expected to have a more material impact to the system. In this case, end users should (hopefully) opt for the 95% solution and address the 5% in another way to keep the customization as simple as possible and maintain optimal system performance.

Salto Tip: When you next design a NetSuite customization, make sure to share the expected system performance impact of such a customization with your stakeholders so they can contemplate a revised scope (if necessary) that balances system performance with the need to solve the problem.

‍

Mistake 2 - Not leveraging all of the tools at your disposal

The best way to review your NetSuite system performance at a much deeper level is to leverage the NetSuite APM solution. This is a free add-on offered by NetSuite and can be downloaded from the SuiteApp Marketplace.

Navigate: Customization – SuiteCloud Development – SuiteApp Marketplace – Type “APM” in the search bar – Click on “Application Performance Management (APM)” tile - Install

Once you have installed the APM solution, consider the following steps:

(1) Perform an initial investigation of your system performance

(2) Identify the “problem children” by referencing response times - those with longer response times require further investigation

(3) Take remediation steps to address the issues - prioritize based upon records most heavily used in the system with the highest response times.

For a more detailed walkthrough of the above process, check out this blog post: “Is NetSuite running slow? Find out why”

‍

Mistake 3 - Avoiding scheduled processes

Not every NetSuite customization needs to execute point in time (think user event/client script). In fact, when designing a custom NetSuite solution, serious thought should be given as to whether that particular process can be executed on a scheduled basis, daily perhaps.

If you plan to transform field values on a form based upon user input, or input from an external source, consider whether that transformation needs to happen at the time the record is created/edited or whether the transformation can take place later in the day or possibly overnight.  Another consideration is the volume of records that the customization will impact. If it will impact a large number of records, there is benefit to running the transformation outside of business hours, so as to not cause disruption during peak system usage.

When scheduling a process it is important to identify the appropriate script type. Many users will opt for the more traditional scheduled script when in fact they would be better served deploying a map/reduce script. In general, map/reduce scripts should be leveraged when processing large volumes of data, as the script will run more efficiently when compared to a scheduled script. For lower volume updates, a simpler, scheduled script should suffice.

Salto Tip: Run scheduled scripts during “off peak” hours for your business. If your business operates 24/7, then consider times that will be least impactful or, better yet, consider if the process can instead be run weekly, over the weekend.

‍

Mistake 4 - Not baking system performance improvements into the process

As NetSuite Administrators and Developers, we spend a lot of energy and focus on new system customizations. As a result, we do not allow ourselves the time to take a step back and manage any cumbersome technical debt that has built up over the years of using the system.

It is imperative that system performance improvements are baked into your development lifecycle. This may come at the expense of not completing every system enhancement requested, but it is important to remind your end users of the importance of system performance—especially as they will be the first to report performance issues. Carve out the time to focus on these improvements and your end users will thank you for it in the long run.

One way to influence the decision to allow time for performance improvements is to be transparent with your end users. Show them the latest NetSuite APM dashboard so they can better visualize the challenges you plan to tackle. Take it one step further by showing them the system performance results before and after an improvement that was recently implemented.

‍

Mistake 5 - Forgetting to evaluate system performance before and after

Evaluating the system performance before undertaking any major NetSuite enhancement is essential. In some cases, the enhancement may be focused on improving system performance, e.g. reducing the time taken to integrate 1,000 sales orders from external CRM to NetSuite. In this use case, the need to measure the performance before and after is obvious, but for other system customizations we often forget about the performance.

Not only is it important to capture the system performance beforehand, it’s also important to capture the system performance afterward. Your customization could check every box during testing and be ready for Production migration, but once it’s migrated and users start to complain about how slow a particular record has become to work with, you may find yourself either spending time trying to figure out which customization is causing the issue or, after finding the issue, needing to rollback the change because the impact to performance was too severe.

Another great way to challenge user requests, to determine their validity/priority, is to share the current performance of the record(s) they would like to enhance and confirm whether they are open to any level of performance impact if the proposed changes are made. I wonder how many requests would get deprioritized if this approach was adopted more broadly.

Salto Tip: Take screenshots of system performance details both before and after deploying a customization in your NetSuite Sandbox account and share this with your stakeholders. This will help to keep stakeholders accountable for the impact that changes they propose may have on system performance.

‍

Mistake 6 - Querying vast amounts of data via saved searches

Saved searches can get complex very quickly and will vary in performance largely based upon the volume of data that is being looked up. For example, if you are running a transaction saved search in a brand new NetSuite environment, you can expect the results to render almost instantaneously compared to an environment with millions of transaction lines where you should expect to wait a little longer for the results to render. Knowing this, here are a few specific recommendations for improving saved search performance:

1. Be extra specific with your criteria. The more specific your criteria, the fewer results that needed to be rendered.
2. Keep columns to a minimum. Only add fields to the “Results” tab if they are important to understanding the data. The more columns in the report, the more data NetSuite needs to look up and output.
3. Minimize grouping. Only group your saved search results when necessary. Grouping will typically take longer to produce the results vs the underlying data that makes up the grouped results.
4. Break into multiple searches. This is more typical when working with transaction saved searches. If you require data for a fiscal year and the results are taking a long time to render, consider creating separate searches to break up the data into fiscal quarters.
5. Schedule. Saved searches can deliver lightning fast, on-demand insights into your company, but consider which results are needed real-time and which can be scheduled. Schedule less critical saved searches during off peak hours, so that you have all the saved search results you need sent right to your inbox and ready for when you first log on the next day.

‍

Mistake 7 - Ignoring governance limits

Depending upon your NetSuite license tier and number of available SuiteCloud Plus licenses, your NetSuite environment may have different governance limits compared to other NetSuite customers.

One thing to consider is upgrading your NetSuite tier or purchasing additional SuiteCloud Plus licenses to enhance your existing governance limits, especially if scripts are failing to process or failing to execute after running out of available processing units. This also applies to API calls in/out of NetSuite and is even more prevalent when these calls involve large volumes of records. Before going down this route, it is recommended to work with NetSuite directly to perform a review of your account and see if your current NetSuite usage would qualify for an increased tier and/or additional SuiteCloud Plus licenses. 

Even if you are not sure if your NetSuite environment is ready for an upgrade it is worth considering going through the system review process to help gauge where you are at today and identify how much runway you have before an upgrade might be required.

‍

Best Practices When Thinking About NetSuite Performance

1. Take the time to design and build efficient SuiteScripts and Workflows in NetSuite. Overengineering can lead to significant performance challenges, even if the solution produces the desired system output.
   ‍
2. If you haven’t already, download the NetSuite APM SuiteApp from the SuiteApp Marketplace. Use APM to review the records that take the longest to load and save, then execute a plan to address the root cause of these performance issues.
   ‍
3. Wherever possible, have customizations run on a scheduled basis vs point in time and schedule outside of core business hours.
   ‍
4. Revisit your process for managing NetSuite system enhancements; ensure the right amount of time is set aside to focus on optimizing existing solutions and not solely on new customizations.
   ‍
5. Ensure that your unit testing scenarios include tests to evaluate the system performance both before and after a new customization is implemented.
   ‍
6. Revise saved searches that pull large amounts of data in a single system query and instead restrict the criteria to exactly what is needed (or consider breaking up into several saved searches).
   ‍
7. Review governance limits regularly (you should leverage NetSuite APM for this). Do not wait for scripts to error or integrations to fail, and be proactive when it comes to addressing governance limits. Sometimes, this can be as simple as scheduling a process to run 30 minutes after it was previously scheduled; other times, you might need to revisit your NetSuite tier and/or SuiteCloud Plus licenses.
   ‍
8. Work with end users to clean up their dashboards. Many users will have portlets and reminders they are not using but which they still keep  on their dashboard, not knowing that they impact dashboard load time.
   ‍
9. Where possible, leverage out of the box system functionality vs resorting to customization. Yes, sometimes it is better to use core functionality that is supported and already optimized for performance as opposed to  trying to create your own custom solutions. 
   ‍
10.  Favor header level field customizations over line level field customizations. Header level fields are generally easier to work with because they have a 1:1 relationship between record and field whereas line level fields have a 1:X relationship. Line level field customization will typically require SuiteScript development that executes on every line rather than just at the header. Consider a record with 100 lines; it is more efficient to execute a process at the header level than at the line level because the process will need to run 100 times more when processing at the line level.
    ‍

For more information on these best practices, check out this blog post that explores some of the things that NetSuite Developers and NetSuite Administrators overlook when working with NetSuite user roles and permissions.

‍

‍

Final thoughts

NetSuite is a very powerful tool and, when implemented properly, it can truly be transformational. With great power (to customize) comes great responsibility in the form of maintaining the system. It is essential to keep system performance top of mind even shortly after implementing NetSuite. System performance challenges can get out of hand relatively quickly if not being actively monitored or remediated.

NetSuite provides all of the necessary tools to manage the system performance, so that is not the challenge. Instead, as NetSuite Developers and Administrators, we struggle to make the time to focus on system performance with the backlog of enhancements and development requests to be prioritized. It is important to remind your stakeholders of the importance of system performance and that it should be taken into consideration for all future system customizations. Sharing the direct performance impact of a proposed customization with the requester can be eye opening and can sometimes lead to the cancellation of requests where the requested functionality does not justify the system performance impact.