Salto for
NetSuite
Articles
SHARE
Sonny Spencer, BFP, ACA
February 14, 2025
11
min read
The ability to create entirely custom solutions in NetSuite gives NetSuite professionals the ability to support their business needs without compromising the core architecture of the platform. Custom records are the foundation for many of these custom solutions. You only have to look at the NetSuite partner ecosystem to find all sorts of creative and targeted solutions that have been created to solve some of the more common business challenges that are not served out of the box.
In this article we are going to explore some of the best practices and important considerations when building your own custom solution, leveraging custom records.
Salto Tip: The best partner solutions (think SuiteApps and SuiteBundles) will combine the ability to create custom records with SuiteScript and SuiteFlow to extend the solutions beyond more basic data entry and collection.
In a previous article we discussed the importance of creating custom records. We are going to look at the importance of getting them right.
SuiteScript and SuiteFlow are generally used for business process automation in NetSuite. Custom records facilitate the capture of key data points to facilitate that automation. They can also be used for raw data capture to support further business analysis.
Whatever the use case may be it is important to keep the number of custom fields to a minimum. Not to simplify the development process, but to force end users to deeply consider which fields are critical to the process. Every custom field that needs to be populated manually will add to the total time taken to complete a single record. If you are designing a custom record in support of an online form to be used by customers or vendors you will need to think through the amount of data you want them to capture - again keeping it to the most critical fields.
Salto Tip: In addition to custom fields, consider other out of the box fields that can be displayed on a custom record and whether they should be displayed. For example, do you need to show the record owner? Why? Is the last modified date on the record important? Does the record need a name? Ask yourself these questions as you are creating your custom record for the first time.
Screenshot of custom record creations screen, showing out of the data points available for selection
There are many use cases for standalone custom records. Making them accessible for end users to populate can be challenging if not managed correctly. You do not want your end users navigating to the custom record list and clicking on “New Record” every time they need to create new data in the system.
Screenshot of the Record Types page in NetSuite where users can create new records for a given custom record
Instead leverage custom center tabs, custom center categories and custom center links to drive end user navigation to these custom records. The navigation path should be intuitive. If you have created a customer survey then consider displaying the custom record creation under the “Customers” center tab for user roles with the “Accounting Center” center type.
You should also consider the hierarchy of your custom records. Does this record belong on an existing system record? Going back to our customer survey example, you might expect the results of the customer survey to live on the customer record itself. This is a simple enough exercise. Create a custom field on your custom record that references the “List/Record” for “Customer” and check the box “Record is Parent”. This establishes a parent/child relationship between the customer record and the customer survey record. You can use this same process to link other records in the system as well and in doing so make it much easier for your end users to navigate NetSuite and quickly access the data points they need without having to go to a separate list of results.
Screenshot showing a custom entity field that can be created to establish a parent/child hierarchy between one record and a customer record
As mentioned earlier, NetSuite partners extensively leverage custom records when building custom solutions to meet the needs of their customers. In that, custom records do not need to be available to end users for data population. In fact, some of the most useful custom records are hidden from end users entirely.
Imagine you are building a custom solution that requires different attributes to be populated based upon the country of the underlying record the custom solution is executing against. Banking is a good example, as banking requirements will typically differ country by country. One option would be to hard code values in SuiteScript for all countries or accounting for exceptions. This could get the job done, but is not scalable at all. Any changes to the requirements in the future would require a code change.
Instead, these values can be populated on country-specific custom records. The script can then reference the values populated in the custom records with reference to the country value itself. That way, as requirements change in the future the underlying custom record for a given country can be populated and the code remains unchanged/stable. This is just one example of how custom records can be leveraged beyond more simple data collection efforts.
NetSuite continues to innovate across all key areas of the platform. Let’s explore some of the latest enhancements to these features.
Custom records are a long standing customization feature in NetSuite so there is not much in the way of updates to custom records themselves in the latest NetSuite releases, however in the 2024.2 release there was an update related to how users access custom records.
In order to provide more governance over users that can access custom record entries in the system, NetSuite has introduced a more robust user security setup. More specifically, the “No Permissions Required” access type has now been renamed to “No Permissions Required for Internal Roles”. This selection can be made when you need to allow a custom record to be available to internal roles without requiring the specific permission. More details can be found here in SuiteAnswers.
Here are links to the latest NetSuite Release Notes for quick reference.
NetSuite custom records offer a wealth of configuration options, making it challenging to manage them all effectively especially with multiple projects running simultaneously. Manual migration between NetSuite environments is not only time-consuming, but also carries a higher risk of human error. In fact, a single incorrect setting can have serious repercussions in your Production environment.
For example, an incorrect “Access Type” setting during your production migration could lead to unintended user access to the custom record and therefore any future data generated from it. This could go unnoticed until it's too late. If the custom record contains sensitive data such as employee feedback, having inadequate security could have severe consequences for the business.
More generally, consider a larger NetSuite customization that involves scripts, workflows, saved searches and other custom records. Attempting to migrate such complex solutions manually becomes a painful process for NetSuite Administrators. This labor-intensive deployment process is highly susceptible to environment dependency issues, which only further delay the deployment process and reduce the speed to providing value to the business.
The ability to quickly compare NetSuite environments beforehand would significantly benefit NetSuite Admin Teams, in addition to being able to deploy larger customizations to production seamlessly.
Not sure how costly getting deployments wrong can be to your business? Check out this blog post (with a calculator) to help you make that assessment.
Now, let’s explore solutions to these challenges.
It can be incredibly painful for any NetSuite Administrator to manage NetSuite custom records between different environments, especially if attempting to do it manually.
Attempting to migrate custom record solutions manually results in a HIGH level of risk given the large number of configuration settings on any one custom record, let alone all related customizations.
NetSuite offers a number of out of the box solutions to manage the migration of these solutions. Copy to Account, SuiteBundler and the SuiteCloud Development Framework (SDF) are options to consider, each with their own pros and cons. Review these native customization migration tools to see which would be the most effective for migrating your particular customized solution to the Production environment. The right approach could vary based upon the complexity of your custom solution.
Working across multiple NetSuite environments, which generally contain active development in different stages of completion, can be a struggle for NetSuite Admin teams to manage. To accommodate all of these moving parts, they are considering alternative solutions. Salto is one of these solutions - check out the Salto SuiteApp. The Salto platform allows NetSuite Administrators to perform environment comparisons across the various environments they manage, making for a much easier way to identify any potential deployment conflicts in advance vs finding out after the fact.
When working with custom records the potential for deployment conflicts is higher due to their connectivity with many other customization areas in NetSuite. This will slow down any deployment process by forcing a more in-depth review of potential conflicts or even accepting the creation of duplicate customization components in production, which need to be cleaned up.
In addition, Salto gives NetSuite Administrators the flexibility to execute deployment rollbacks quickly and seamlessly in the situation where a deployment to Production was pushed and unexpected issues arose. While this should not happen often, rollbacks are a high priority when needed, so having the ability to manage the rollback process within minutes and not hours is a game changer for any NetSuite Admin Team.
Now that you have successfully deployed your custom NetSuite solutions to Production, let’s consider some best practices that NetSuite Administrators should adopt when working with custom record solutions.
Salto Tip: Check out this FREE NetSuite Administrator training course on Salto Leap to see how you can become a Master NetSuite Administrator and NetSuite guru for your company.
For more Best Practices to manage your NetSuite customizations, check out Salto’s blog posts that explore some of the things that NetSuite Developers and NetSuite Administrators should be leveraging within the NetSuite ecosystem.
Custom records are a powerful customization tool in NetSuite. When implemented correctly, they can streamline business processes through more advanced customization with SuiteScript and SuiteFlow. They can also be used to capture business critical data points that are otherwise not available out of the box in NetSuite.
Before you jump in and start designing a custom build, consider the pros and cons of building and maintaining the solution in-house vs leveraging an existing, established solution through the SuiteApp marketplace. It is more than likely that the problem you are attempting to solve has been faced by many other companies to the point that a NetSuite partner has already solved it, if NetSuite hasn’t already solved it and made it available out of the box.
Custom records are point and click solutions. You do not need to be a software developer to extend your NetSuite instance and add immediate value to your business. NetSuite Administrators should take advantage of this flexible customization tool within the system, but only after deeply understanding the business requirements.
Salto for
NetSuite
NetSuite
SHARE
Sonny Spencer, BFP, ACA
February 14, 2025
11
min read
The ability to create entirely custom solutions in NetSuite gives NetSuite professionals the ability to support their business needs without compromising the core architecture of the platform. Custom records are the foundation for many of these custom solutions. You only have to look at the NetSuite partner ecosystem to find all sorts of creative and targeted solutions that have been created to solve some of the more common business challenges that are not served out of the box.
In this article we are going to explore some of the best practices and important considerations when building your own custom solution, leveraging custom records.
Salto Tip: The best partner solutions (think SuiteApps and SuiteBundles) will combine the ability to create custom records with SuiteScript and SuiteFlow to extend the solutions beyond more basic data entry and collection.
In a previous article we discussed the importance of creating custom records. We are going to look at the importance of getting them right.
SuiteScript and SuiteFlow are generally used for business process automation in NetSuite. Custom records facilitate the capture of key data points to facilitate that automation. They can also be used for raw data capture to support further business analysis.
Whatever the use case may be it is important to keep the number of custom fields to a minimum. Not to simplify the development process, but to force end users to deeply consider which fields are critical to the process. Every custom field that needs to be populated manually will add to the total time taken to complete a single record. If you are designing a custom record in support of an online form to be used by customers or vendors you will need to think through the amount of data you want them to capture - again keeping it to the most critical fields.
Salto Tip: In addition to custom fields, consider other out of the box fields that can be displayed on a custom record and whether they should be displayed. For example, do you need to show the record owner? Why? Is the last modified date on the record important? Does the record need a name? Ask yourself these questions as you are creating your custom record for the first time.
Screenshot of custom record creations screen, showing out of the data points available for selection
There are many use cases for standalone custom records. Making them accessible for end users to populate can be challenging if not managed correctly. You do not want your end users navigating to the custom record list and clicking on “New Record” every time they need to create new data in the system.
Screenshot of the Record Types page in NetSuite where users can create new records for a given custom record
Instead leverage custom center tabs, custom center categories and custom center links to drive end user navigation to these custom records. The navigation path should be intuitive. If you have created a customer survey then consider displaying the custom record creation under the “Customers” center tab for user roles with the “Accounting Center” center type.
You should also consider the hierarchy of your custom records. Does this record belong on an existing system record? Going back to our customer survey example, you might expect the results of the customer survey to live on the customer record itself. This is a simple enough exercise. Create a custom field on your custom record that references the “List/Record” for “Customer” and check the box “Record is Parent”. This establishes a parent/child relationship between the customer record and the customer survey record. You can use this same process to link other records in the system as well and in doing so make it much easier for your end users to navigate NetSuite and quickly access the data points they need without having to go to a separate list of results.
Screenshot showing a custom entity field that can be created to establish a parent/child hierarchy between one record and a customer record
As mentioned earlier, NetSuite partners extensively leverage custom records when building custom solutions to meet the needs of their customers. In that, custom records do not need to be available to end users for data population. In fact, some of the most useful custom records are hidden from end users entirely.
Imagine you are building a custom solution that requires different attributes to be populated based upon the country of the underlying record the custom solution is executing against. Banking is a good example, as banking requirements will typically differ country by country. One option would be to hard code values in SuiteScript for all countries or accounting for exceptions. This could get the job done, but is not scalable at all. Any changes to the requirements in the future would require a code change.
Instead, these values can be populated on country-specific custom records. The script can then reference the values populated in the custom records with reference to the country value itself. That way, as requirements change in the future the underlying custom record for a given country can be populated and the code remains unchanged/stable. This is just one example of how custom records can be leveraged beyond more simple data collection efforts.
NetSuite continues to innovate across all key areas of the platform. Let’s explore some of the latest enhancements to these features.
Custom records are a long standing customization feature in NetSuite so there is not much in the way of updates to custom records themselves in the latest NetSuite releases, however in the 2024.2 release there was an update related to how users access custom records.
In order to provide more governance over users that can access custom record entries in the system, NetSuite has introduced a more robust user security setup. More specifically, the “No Permissions Required” access type has now been renamed to “No Permissions Required for Internal Roles”. This selection can be made when you need to allow a custom record to be available to internal roles without requiring the specific permission. More details can be found here in SuiteAnswers.
Here are links to the latest NetSuite Release Notes for quick reference.
NetSuite custom records offer a wealth of configuration options, making it challenging to manage them all effectively especially with multiple projects running simultaneously. Manual migration between NetSuite environments is not only time-consuming, but also carries a higher risk of human error. In fact, a single incorrect setting can have serious repercussions in your Production environment.
For example, an incorrect “Access Type” setting during your production migration could lead to unintended user access to the custom record and therefore any future data generated from it. This could go unnoticed until it's too late. If the custom record contains sensitive data such as employee feedback, having inadequate security could have severe consequences for the business.
More generally, consider a larger NetSuite customization that involves scripts, workflows, saved searches and other custom records. Attempting to migrate such complex solutions manually becomes a painful process for NetSuite Administrators. This labor-intensive deployment process is highly susceptible to environment dependency issues, which only further delay the deployment process and reduce the speed to providing value to the business.
The ability to quickly compare NetSuite environments beforehand would significantly benefit NetSuite Admin Teams, in addition to being able to deploy larger customizations to production seamlessly.
Not sure how costly getting deployments wrong can be to your business? Check out this blog post (with a calculator) to help you make that assessment.
Now, let’s explore solutions to these challenges.
It can be incredibly painful for any NetSuite Administrator to manage NetSuite custom records between different environments, especially if attempting to do it manually.
Attempting to migrate custom record solutions manually results in a HIGH level of risk given the large number of configuration settings on any one custom record, let alone all related customizations.
NetSuite offers a number of out of the box solutions to manage the migration of these solutions. Copy to Account, SuiteBundler and the SuiteCloud Development Framework (SDF) are options to consider, each with their own pros and cons. Review these native customization migration tools to see which would be the most effective for migrating your particular customized solution to the Production environment. The right approach could vary based upon the complexity of your custom solution.
Working across multiple NetSuite environments, which generally contain active development in different stages of completion, can be a struggle for NetSuite Admin teams to manage. To accommodate all of these moving parts, they are considering alternative solutions. Salto is one of these solutions - check out the Salto SuiteApp. The Salto platform allows NetSuite Administrators to perform environment comparisons across the various environments they manage, making for a much easier way to identify any potential deployment conflicts in advance vs finding out after the fact.
When working with custom records the potential for deployment conflicts is higher due to their connectivity with many other customization areas in NetSuite. This will slow down any deployment process by forcing a more in-depth review of potential conflicts or even accepting the creation of duplicate customization components in production, which need to be cleaned up.
In addition, Salto gives NetSuite Administrators the flexibility to execute deployment rollbacks quickly and seamlessly in the situation where a deployment to Production was pushed and unexpected issues arose. While this should not happen often, rollbacks are a high priority when needed, so having the ability to manage the rollback process within minutes and not hours is a game changer for any NetSuite Admin Team.
Now that you have successfully deployed your custom NetSuite solutions to Production, let’s consider some best practices that NetSuite Administrators should adopt when working with custom record solutions.
Salto Tip: Check out this FREE NetSuite Administrator training course on Salto Leap to see how you can become a Master NetSuite Administrator and NetSuite guru for your company.
For more Best Practices to manage your NetSuite customizations, check out Salto’s blog posts that explore some of the things that NetSuite Developers and NetSuite Administrators should be leveraging within the NetSuite ecosystem.
Custom records are a powerful customization tool in NetSuite. When implemented correctly, they can streamline business processes through more advanced customization with SuiteScript and SuiteFlow. They can also be used to capture business critical data points that are otherwise not available out of the box in NetSuite.
Before you jump in and start designing a custom build, consider the pros and cons of building and maintaining the solution in-house vs leveraging an existing, established solution through the SuiteApp marketplace. It is more than likely that the problem you are attempting to solve has been faced by many other companies to the point that a NetSuite partner has already solved it, if NetSuite hasn’t already solved it and made it available out of the box.
Custom records are point and click solutions. You do not need to be a software developer to extend your NetSuite instance and add immediate value to your business. NetSuite Administrators should take advantage of this flexible customization tool within the system, but only after deeply understanding the business requirements.