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

‍

Introduction

One of the many benefits of working with NetSuite ERP is the ability to customize the system to meet your specific business requirements. Many of these customizations can be performed with point and click solutions, which is attractive for companies that have limited developer resources available to them. At the same time, NetSuite allows its customers to get as complicated as they wish with customizations by utilizing SuiteScript and various options for integrating data to/from NetSuite.

Regardless of the level of the complexity of a NetSuite customization, there are a number of common mistakes that NetSuite Administrators and Developers make today. In this blog post we will explore 8 of the most common mistakes I have seen in my time using NetSuite.

‍

‍

Mistake 1 - Forgetting to customize IDs

When creating new NetSuite objects and records within the system, NetSuite will provide a default ID value, e.g. customsearch123.

This ID reference is not the most helpful from a reference point of view. It is unique, but it provides little to no information as to what this record is. Take the time to update the IDs for all NetSuite customizations and replace references like “customsearch123” with “Company Name_revenue_by_customer”, for example.

Using consistent naming conventions for NetSuite IDs will allow users to quickly identify customizations added by the company vs that of NetSuite or a third party. Further, when working with these objects in SuiteScript, it is helpful for NetSuite developers to have some understanding of what the custom record/object does and the system default IDs do not cut it.

Salto Tip: Many records allow you to update the ID after the fact, so if you notice an object or record without a unique ID, consider updating it. Before making the update, first validate that the record does not have any dependencies, otherwise you risk breaking any related customizations.

‍

Mistake 2 - Not thinking about field validation

When working with custom fields in NetSuite, it is important to consider field validation. Think about the end user behavior you are trying to drive. If you want the user to always populate a field prior to saving the record, set the field to be mandatory. Taking this one step further, if you want the field to always be populated on any form that references this field, then set the field to be mandatory on the field record itself. If the field should only be mandatory for certain forms, then do not make the field mandatory on the field record, but instead make the field mandatory only on the required custom forms.

Also give extra consideration as to whether a new custom field should be populated by the user or by a separate process (think SuiteFlow or SuiteScript). If the latter, consider setting the display type to “Inline Text” as opposed to “Normal” or possibly “Hidden” if the field value is not important to your end users.

Salto Tip: In SuiteScript, only user event, scheduled, and Suitelet scripts can set the value of a custom field that has a display type of “Hidden”.

‍

Mistake 3 - Losing sight of regional differences

For any NetSuite OneWorld customer, it is easy to lose sight of regional differences when receiving customization requests from one particular region. For example, perhaps the team in North America would like to implement a new vendor bill approval workflow.

Before jumping into requirement gathering and customization for North America, you should consider the impact to other regions. Perhaps the team in Asia or EMEA would like the same customization, so the solution could be deployed on a global scale. In any case, you will need to ensure you have the subsidiary access for each object set up appropriately to restrict access to the required regions. 

There are pros and cons to taking a phased approach vs a big bang approach when implementing new customization. Take the time to ensure you are taking the right approach for each customization.

You should also consider user role permissions here. If you have similar roles for different regions you may need to update permissions for some roles, but not others.

‍

Mistake 4 - Ignoring user access

Before kicking off any new NetSuite customization it is critical to understand which user roles are required to execute the process. You then need to ensure appropriate access is granted to any new objects and/or records included in the new solution as well as update user role permissions in the case of new record types.

This is a very common occurrence where a solution has been fully tested and deployed to production only for the users to complain that they cannot access the required records, or even worse that users who should not have access to these records do.

This is important to continue operating under the principle of least privilege, so ensure user access is considered in each and every NetSuite customization.

‍

Mistake 5 - Disregard system performance

You can develop a fantastic SuiteScript solution that meets all of your end user’s requirements, but if it results in a significant delay loading/saving the related scripted records, you could be doing more harm than good from an efficiency perspective.

Different customizations will have varying impacts to system performance. For example, a SuiteScript that executes at the header level of a transaction will (for the most part) have less of a performance impact than a similar script executing at the line level of the same transaction. This is especially true on transactions with a large volume of transactions. Introduce line level customizations with caution and ensure you test both functionality and performance prior to migrating the solution to production.

Something to consider is baking system performance testing into your development process. That way, users can be informed of the direct system performance impact of the proposed customization, possibly resulting  in a delay or deferral of the production deployment until a more efficient solution has been developed.

‍

Mistake 6 - Inadvertently introducing dependencies

For most NetSuite admins and developers, customization starts in a sandbox or development environment. These customizations rarely occur one at a time; in fact, it is common for many planned customizations to be built at the same time, independently and often by separate developers.

Without appropriate oversight, two (or more) separate customizations can inadvertently impact one another. For example, if one developer is working on a SuiteScript solution to add new functionality to the sales order transaction record and an administrator is separately working on cleaning up sales order transaction forms, there is potential to introduce some inadvertent dependencies across the two customizations.

This does not mean you should only develop one solution at a time in a sandbox or development environment. That would slow you down significantly. Instead, ensure you have a central team/system architect that is aware of all customization taking place in a NetSuite environment, so they can consider the risk of creating dependencies. If the risk is significant, then you should consider running the development in parallel and testing both solutions at the same time. That way, any conflicts introduced will be identified and remediated during end user testing rather than be identified in production.

If the risk is negligible then development can proceed independently.

‍

Mistake 7 - Only testing with the Administrator role

I see this too often—where NetSuite developers will test a process end to end with the Administrator role but forget to test in the role of the end user. Successful unit testing then results in a close to immediate failure of user acceptance testing because the user roles do not have the appropriate permissions to access/work with the new customization. This is more typical when working with new NetSuite custom records.

Ensure that when documenting requirements for a NetSuite customization you capture the end user roles that require access to work with the customization and in what capacity, e.g. view access vs edit access.

In both unit testing and user acceptance testing documentation, ensure you have a column to confirm the NetSuite user role that should be testing each scenario. This should minimize the risk that solutions are developed without thought to the end user roles that will be working with the solution in Production.

‍

Mistake 8 - Not planning for production migration

Even the best NetSuite solution that has been masterfully developed and fully tested end to end can still run into issues if the production migration strategy is not right.

Timing is important. Generally, customizations should not be deployed to production on or around critical business operations, such as quarter end close or year end close. This is to mitigate the risk of causing any unwanted impact to users during these critical periods of system use. Ideally, solutions will be deployed on a scheduled basis with blackout periods (code freezes) communicated in advance. This sets expectations with your end users and provides consistency for the team deploying these solutions.

Arguably more important than timing is the production migration approach. There are a number of ways in which NetSuite administrators can deploy changes from one environment to another and it is vital the correct approach is taken to minimize the risk of something going wrong during the process.

Manual migration is always an option, but is by far the least preferred method. It is the most time consuming and carries the highest risk of user error.

NetSuite offers a number of options in the form of SuiteBundler, Copy to Account and SuiteCloud Development Framework (SDF). As with anything, there are pros and cons to each of these options, depending upon the objects and records you need to migrate from one environment to another. Both SuiteBundler and Copy to Account are more user friendly solutions for NetSuite Administrators, whereas developers will be drawn toward SDF.

While these options get the job done, another solution to consider is Salto. The Salto SuiteApp helps NetSuite admins and developers manage their NetSuite customizations in a more automated way by speeding up the deployment process. Users have the ability to compare NetSuite environments to help identify differences between them, as well as confirm record dependencies. The ability to roll back to older versions of NetSuite configuration can be huge in the event a solution deployed to production doesn’t have the desired impact.

‍

Best Practices When Customizing NetSuite

1. Test system performance impact, not just user acceptance testing. Check out the NetSuite APM bundle to support the testing of system performance.
2. Use a consistent format for custom IDs so it is clear which customizations are internal. Example “Company Name_revenue_by_customer”
3. Test customizations in the role of the end user - not Administrator! 
4. Always consider the user interface impact of your customization. If adding custom fields, where they are displayed on page layouts is important.
5. Documentation is often the thing considered last and gets dropped when other priorities take precedent. Make documentation part of your development process, not a separate task to complete at the end of a project.
6. Take the time to future proof. Quick solutions are great, but not at the expense of introducing technical debt.
7. Group similar requests. Instead of working on 3 separate customization requests for a single NetSuite object, group the requests and treat them as a single solution.
8. Have a consistent sandbox refresh policy to minimize the risk of inadvertent dependencies.
9. Have a consistent release schedule for new customizations, e.g. bi-weekly/monthly schedule.
10. Use native NetSuite features whenever possible vs building customizations from scratch. NetSuite offers a wide range of built-in features and customization options that can often meet your requirements without the need for extensive development.

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 customizing NetSuite.

‍

‍

Final thoughts

The above mistakes we reviewed in this blog post are inevitable, even for the most diligent NetSuite user. As such, we need to consider how we can minimize this risk we are unable to fully mitigate.

Consider leveraging the above best practices as a checklist to consider throughout the system customization lifecycle—from initial solutioning through to testing and deployment. If you follow these best practices, you will minimize the risk of falling victim to the 8 common mistakes we walked through.