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

‍

Introduction

Custom records are one of my favorite NetSuite objects. Why? Because they allow each NetSuite customer to engage with NetSuite in an entirely unique way that supports their business requirements. Not only can you create a completely custom form, with custom fields, layout, etc., you can create parent/child relationships between these records to build larger custom solutions. In this blog post here we looked at how to build out a lightweight project management record that could track project details and milestones.

You may have noticed that your NetSuite environment already has a large number of custom records in it, many of which you cannot modify. That is because most NetSuite add-ons (think NetSuite modules and SuiteApps) leverage the power of custom records in the development to coincide with custom scripts, workflows and other objects.

In this blog post, we will explore some of the mistakes I have seen from NetSuite Administrators and Developers so that you won’t make those same mistakes when next creating a custom record in NetSuite.

Salto Tip: Refer to the best practices for creating custom records at the end of this blog post when you create your next custom record to avoid making any of these mistakes in future.

‍

‍

Mistake 1 - Not assigning user role permissions

The good news with this potential mistake is that NetSuite sets the recommended “Access Type” value by default, being “Require Custom Record Entries Permission”. This field value on the custom record is critical because it governs the security profile for this custom record and how users may (or may not) interact with it.

Once this value is set, you will need to update each and every role (except for Administrator) that needs to work with this custom record to add this custom record role permission and set the appropriate permission level (view/create/edit - full generally not recommended).

You might be tempted, for simplicity, to set the “Access Type” to “Use Permission List”. While this does the same job from a security access perspective, you need to consider scalability. When creating new user roles in the future, will you remember to update every custom record type to set the appropriate access for that role or are you more likely to add the permission when creating a new user role? More than likely you will be copying an existing user role that already has the custom record role permission and no additional effort is required at all. That is why I recommend the NetSuite default value.

“No Permission Required” is almost never recommended. The only exception would be a custom record that every user in the system should have access to. If you can validate that is the case, then you shouldn’t waste time adding a custom record role permission to every system role. This exception should be extremely rare. If in doubt, have user role permissions determine the appropriate system access for each NetSuite object/record.

‍

‍

Mistake 2 - Forgetting to link to the parent record

Before creating a new custom record in NetSuite think about how it relates to existing records in the system. Ask yourself if it would be beneficial to link this record to the customer record, vendor record or any other record for that matter (including another custom record).

In fact, the ability to link custom records in a parent / child hierarchy allows you to create more complex solutions in the system. Also consider your end users who will work with these records. For linked records, it will be helpful for them to be able to reference these related records within one another vs searching for a linked record. 

Salto Tip: Don’t forget that you cannot directly link two records by referencing the “Child Records” and “Parent Records” tabs on the custom record itself. Instead you must first create a custom field (list/record type) that references the parent record. “Record is Parent” should be checked on this custom field. The records will then be linked in a parent / child hierarchy.

‍

‍

Mistake 3 - Not fully understanding what each checkbox does

Custom records have numerous configuration options available, many of which are in the form of a check box. For some of these configuration options the field naming convention gives you a very good idea about what checking that box will do, e.g. “Allow Attachments”, which unsurprisingly will allow users to attach documents to the custom record.  “Enable Optimistic Locking”  returns an error when multiple users are editing the same record. Specifically, if user A saves a change then user B attempts to save a change for the same record, user B will receive an error to avoid conflicts.

Take the time to understand the functionality of each check box on the custom record form. This blog post provides clarity on each of these check boxes.

‍

‍

Mistake 4 - Not taking the time to plan.

It is essential that you take the time to properly plan for the creation of a new custom record in your NetSuite environment. This adds a new custom table in the database that is unique to your business, so it should be well thought out before it is created.

Work with your end users to understand the business use case(s) you need to solve. Start at the highest level by determining the parent / child structure of the custom records, then move into custom fields and forms before finalizing user access permissions.

Keep the solution simple to support the change management process and involve your end users throughout so that you do not receive additional customization requests after migrating the solution from your Sandbox environment to Production.

‍

Mistake 5 - Using custom records in a vacuum

Custom records allow NetSuite Administrators and Developers to create bespoke solutions without the need for custom workflows and scripts. However, custom records are often best utilized as part of a larger solution that involves all of these objects and more. In other words, custom records can help supplement the build of a larger NetSuite customization to streamline the development process.

For example, scripts can reference custom records and values within them (think script parameters). This is a great alternative to hard coding values in the script itself, especially if these values are expected to change over time or if these values could change as new subsidiaries are onboarded into the system.

When updates are required in the future, a NetSuite Administrator need only update the custom record value instead of changing the script code itself. This reduces risk, keeps the change management simple and allows NetSuite Developers to focus on more value add initiatives rather than tweaking existing scripts. The same applies to workflows as well.

‍

Mistake 6 - Trying to reinvent the wheel

When you are looking to solve a bigger business challenge, you should not immediately assume that jumping into building a custom solution is the best option. All businesses have unique challenges they are trying to solve, but many are facing similar issues and that creates a demand for custom NetSuite solutions.

As such, before attempting to build a solution yourself, consider whether someone else has already solved this problem. It is quite possible they have and also possible that the solution is available in the SuiteApp Marketplace. 

There are pros and cons to building a custom solution in-house vs buying a pre-built solution from a NetSuite partner. Think about the ROI when implementing a pre-built solution before making a decision. Regardless of the decision it is an important step in the development process to first consider whether the problem has already been solved, so you don’t have to reinvent the wheel!

‍

Mistake 7 - Migrating custom records manually

Building a custom solution in NetSuite with custom records can be very time consuming, especially when you consider the testing (and potential development interactions) required in a Sandbox or Development environment.

When your users have signed off on testing and you are ready for deployment, the last thing you want to do is migrate those changes to Production manually. Fortunately, we have several options when it comes to migrating custom records from one environment to another. NetSuite offers several solutions, such as SuiteBundler, Copy to Account and SuiteCloud Development Framework (SDF). As with all solutions, there are pros and cons to each. For simpler solutions, you may opt for SuiteBundler or Copy to Account—just be mindful of catching any record dependencies before deploying. For more complex solutions, you might want to consider SDF.

In addition to this NetSuite functionality, there are alternative solutions to consider, such as Salto. The Salto SuiteApp supports NetSuite Administrators and Developers with their NetSuite deployment process through automation. The solution can compare NetSuite environments to identify differences between them, in addition to calling out any record dependencies that exist. Leveraging a tool like Salto can add tremendous value to NetSuite teams looking to streamline their NetSuite deployment processes.

‍

Mistake 8 - Not providing adequate training

It’s in the name: “custom record”. These records are unique to your business requirements. As such, it is critical that your end users know what is expected from them when interacting with a particular custom record. It should be intuitive as to what is expected from each field and field validation should drive user behavior. 

For users working with custom records, you need to ensure the system navigation is simple and easy to follow, so that after the users have been trained on a new solution / process, they are able to execute effectively from that point on. One way to do this would be to create custom center tabs and center categories. More on that in this blog post.

Salto Tip: Add field help notes for each field on a custom record that are concise and intuitive to follow. This will save your users headaches and your Administrators lots of questions.

‍

Best Practices For Creating Custom Records

1. Set the “Access Type” field to “Require Custom Record Entries Permission”. This will ensure that only users with the role permission to interact with a custom record are able to do so.
2. Link your custom records to the appropriate parent records. Remember you cannot link directly and must first create a custom field (list/record type) that references the parent record. “Record is Parent” should be checked on this custom field.
3. Take the time to understand the functionality of each check box on the custom record form. While the naming convention is pretty intuitive, the actions of checking (or not) are not always clear just from the field name. This blog post here reviews each field in detail.
4. Take the time to plan your custom record build. Do not just dive in and start creating a new record with custom fields, forms, parent/child records. Keep the solution simple and involve any end users who will be using this custom record once deployed to production.
5. Custom records are best utilized as part of larger development projects. Consider using them to streamline scripting and workflow processes, e.g. to pass parameters vs hard coding in a script.
6. Review the SuiteApp Marketplace before starting development. If the proposed solution will require significant development work, consider alternatives, such as a NetSuite partner that may have already solved this business need.
7. Migrate your custom records from Sandbox to Production using a deployment tool—do not migrate customizations manually due to the risk of human error.
8. Once the solution is built, make sure to train your end users on how to interact with the custom record. Include field level help notes that users can reference and instructions on how to access the custom record, e.g. custom center tab/category/link.
9. Keep it simple. Only create necessary custom fields. After all, why create a field that doesn’t need to be populated consistently? Is this data point important for the end user or reporting?
10. Maintain documentation for any custom record created: its purpose, related scripts and workflows, etc. This will be valuable for future reference and troubleshooting.

For more information on these best practices, check out Salto’s blog posts that explore some of the things that NetSuite Developers and NetSuite Administrators should consider when creating custom records. By following these best practices, you can create effective and efficient custom records in NetSuite that support your business processes.

‍

‍

Final thoughts

When designed and built carefully, custom records are one of the most powerful tools in NetSuite. They allow the flexibility for your business to engage with NetSuite in a completely customized and tailored way that is unique to your business needs.

If you’re not creating custom records today as part of either technical or functional NetSuite solutions, try to think of business use cases that require the capture of data in a database and attempt to build a prototype. Fields can be added/removed easily following end user feedback, and then before you know it you will have a brand new table of data to report on directly in NetSuite.

Don’t forget—although all businesses are unique, they face many common challenges. Before building that prototype, consider leveraging NetSuite forums and partners to see if anyone has already solved the business problem you are trying to solve. It’s quite possible there is already a SuiteApp that can take care of this problem for you.