Salto for
NetSuite
Articles
SHARE
Sonny Spencer, BFP, ACA
August 15, 2023
10
min read
About Salto: Salto's platform helps you and your team deploy, track, and manage your NetSuite customizations effortlessly. Learn more here.
The ability to customize NetSuite forms gives NetSuite Administrators and Developers the ability to directly influence how end users engage with the NetSuite user interface on a daily basis. If users are having a positive experience with NetSuite, it is more than likely the user interface has been tailored to meet their daily needs. Conversely if they are having a negative experience it is likely the result of a lack of a customized user interface.
The process of customizing NetSuite forms can be time consuming the first time around. Further, the user experience must be front and center of every customization moving forward to ensure that forms do not become difficult to interact with over time. If you are having users work with NetSuite out of the box with no form customization, you are not leveraging NetSuite to its full potential and your users will not be as satisfied with their NetSuite experience.
In this blog post, we will explore some of the common mistakes made when NetSuite forms are customized with good intentions but fall short.
Salto Tip: It is critical that NetSuite form customization is addressed either during implementation (ideally) or shortly afterward. The more time your end users spend trying to navigate forms the more time they waste, which collectively can add up to a significant amount of time wasted over a short period. Take the time to customize the NetSuite user interface. Your end users will thank you for it!
It is important to remember why we customize NetSuite forms in the first place—to improve the experience of navigating NetSuite for our end users. As such, prior to making any changes to forms in the system you should sit down with your end users to understand how they interact with each form and confirm how they would like to navigate each one.
This will ensure that you deliver form changes that add value to your end users and support the change management process, as your end users were actively engaged in the solution design discussions.
Failure to engage with your end users could result in a bunch of rework needed after deploying the changes if users do not feel the new form layouts are intuitive.
If you are going to invest the time and energy into customizing your NetSuite forms then you should get it right the first time around. That involves “scrubbing” each form to review each field and validate if it is needed or not.
Consider running a saved search for the particular record you are looking to customize and pull all of the fields available. You can then quickly identify which fields have data populated and which do not. You can calculate the % use for each field. This could drive additional form changes. For example, if a field is only populated 50% of the time, but the expectation is that it should be populated 100% of the time, you likely need to make that field mandatory.
Conversely, if a field is populated 100% of the time but not adding any value, consider either removing the field or making it optional (if currently set as mandatory).
End users will typically default to keeping a field on the form if they are not sure whether it is needed or not, so it is important to have the facts ready for the usage of each field to help support decision making.
Have you ever populated a record in NetSuite only to get half way through and the page refreshes, resulting in the loss of data previously entered? This is (unfortunately) a common issue. It is the result of fields not being ordered appropriately on the form.
Some fields will trigger background processes to execute, e.g. customer, vendor, subsidiary, etc. These fields should be populated first so that the background processes can run before the end user populates the remainder of the fields on the form.
Make sure you test this process and confirm the fields are in a logical order, otherwise your end users will have to remember to populate the fields in a specific order to avoid repeating data entry.
Ideally, the “Form” field on each custom form will have its display type set to “Inline Text” or the field will be hidden from the form altogether. In some cases, you may need your end users to select a specific form for one use case and a different form for another, but for the most part users should be interacting with a single form per record type.
As such, the “Form” field should not be edited by the user. To drive the required end user behavior, you should lock down each user role to use specific custom forms. This will ensure consistency for your end users and give them one less field to populate.
Over time, you will naturally add new custom forms to your NetSuite environment. If user roles are not locked down to specific forms, all new custom forms created will be automatically available to your users. This could be confusing for them. In addition, you want to avoid having your end users select the “standard” form, which includes the out of the box format with all custom fields— not ideal for end users to interact with.
When creating custom forms and locking them down to specific user roles, be intentional on the form each role should engage with, e.g. create custom forms for each subsidiary or region or another business segment.
NetSuite allows you to link transaction forms, so that when a user transforms one transaction into another (e.g. sales order to invoice), the system will dictate the form used on the transformed record (invoice record per the example).
This can be especially useful for NetSuite customers who use different sales order forms for different selling models, e.g. software vs services. When the “software” sales order is selected and transformed into an invoice, the system will automatically select the corresponding “software” invoice, assuming it has been set on the “Linked Forms” tab on the custom sales order form.
Salto Tip: In Mistake #4, we discussed locking down forms to specific roles. Note that if a user role is restricted to a specific custom form, the user role preference overrides the form selected on the “Linked Forms” subtab.
Creating new subtabs available on transaction and entity record types is a great way to group custom fields that should be separated from other fields on the form. Perhaps on the customer record you are tracking certain attributes for the business reporting and those attributes should all be populated at the same time; you could create a new subtab entitled “Business Reporting” and include all the appropriate fields under that subtab.
Salto Tip: The first subtab (the leftmost subtab) is important as it will be the first subtab displayed on the page and doesn’t require an additional click to navigate. As such, it should include the most referenced data points on that record—not necessarily the default subtab. Also consider the impact of sublists. Sublists referencing vast amounts of data will take longer to load in the user interface, so you probably don’t want to set a subtab with such a sublist as the default.
While sublists that reference large data volumes can impact the system performance when loading a record, they can be very helpful. They allow users to quickly access related records and thereby navigate the NetSuite platform more efficiently. NetSuite provides some useful sublists out of the box, but consider creating your own, so that they only display the required data points. If the user is able to see all of the data points needed without having to navigate to the related record, that will save them time.
Without clearly defined sublists, users will have to navigate to multiple records in order to obtain the information that they need. This is one of the reasons we end up with so many NetSuite tabs open in our browser at any given time!
Customizing NetSuite forms to meet the needs of your end users will take a significant amount of time—especially if you are enhancing all forms at the same time. Migrating these changes manually from one NetSuite environment (Sandbox) to another (Production) can be painful, not to mention the significant risk there is of human error given the large volume of small changes.
NetSuite Administrators and Developers have a number of options that support migrating custom forms between environments. Out of the box, NetSuite offers SuiteBundler, Copy to Account and SuiteCloud Development Framework (SDF). There are benefits and drawbacks to each of these options. I have found that the more technical folks lean toward SDF to migrate changes, but there can be challenges with record dependencies when migrating custom forms.
These NetSuite solutions help to avoid manual migration efforts. However, there are also other solutions to consider. One such alternative is Salto. The Salto SuiteApp helps NetSuite Administrators and Developers manage their NetSuite customizations, including custom forms, in a more automated way by speeding up the deployment process. Salto can easily compare NetSuite environments to help identify any discrepancies between them, as well as confirm record dependencies. This can be invaluable when migrating custom forms, because the probability of having record dependencies is much higher!
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 customizing forms.
One of the many benefits of implementing NetSuite is the ability to customize the system to meet your specific business needs. That should include how your end users engage with the system. Take the time to customize each form that a user may interact with, so they can operate effectively and efficiently when navigating the tool.
Consider using the above best practices as a checklist when going through your own NetSuite form customization initiative. If you can execute on each of these points you will be setting up your end users for success and they will reciprocate by sharing positive experiences when interacting with NetSuite.
Salto for
NetSuite
NetSuite
SHARE
Sonny Spencer, BFP, ACA
August 15, 2023
10
min read
About Salto: Salto's platform helps you and your team deploy, track, and manage your NetSuite customizations effortlessly. Learn more here.
The ability to customize NetSuite forms gives NetSuite Administrators and Developers the ability to directly influence how end users engage with the NetSuite user interface on a daily basis. If users are having a positive experience with NetSuite, it is more than likely the user interface has been tailored to meet their daily needs. Conversely if they are having a negative experience it is likely the result of a lack of a customized user interface.
The process of customizing NetSuite forms can be time consuming the first time around. Further, the user experience must be front and center of every customization moving forward to ensure that forms do not become difficult to interact with over time. If you are having users work with NetSuite out of the box with no form customization, you are not leveraging NetSuite to its full potential and your users will not be as satisfied with their NetSuite experience.
In this blog post, we will explore some of the common mistakes made when NetSuite forms are customized with good intentions but fall short.
Salto Tip: It is critical that NetSuite form customization is addressed either during implementation (ideally) or shortly afterward. The more time your end users spend trying to navigate forms the more time they waste, which collectively can add up to a significant amount of time wasted over a short period. Take the time to customize the NetSuite user interface. Your end users will thank you for it!
It is important to remember why we customize NetSuite forms in the first place—to improve the experience of navigating NetSuite for our end users. As such, prior to making any changes to forms in the system you should sit down with your end users to understand how they interact with each form and confirm how they would like to navigate each one.
This will ensure that you deliver form changes that add value to your end users and support the change management process, as your end users were actively engaged in the solution design discussions.
Failure to engage with your end users could result in a bunch of rework needed after deploying the changes if users do not feel the new form layouts are intuitive.
If you are going to invest the time and energy into customizing your NetSuite forms then you should get it right the first time around. That involves “scrubbing” each form to review each field and validate if it is needed or not.
Consider running a saved search for the particular record you are looking to customize and pull all of the fields available. You can then quickly identify which fields have data populated and which do not. You can calculate the % use for each field. This could drive additional form changes. For example, if a field is only populated 50% of the time, but the expectation is that it should be populated 100% of the time, you likely need to make that field mandatory.
Conversely, if a field is populated 100% of the time but not adding any value, consider either removing the field or making it optional (if currently set as mandatory).
End users will typically default to keeping a field on the form if they are not sure whether it is needed or not, so it is important to have the facts ready for the usage of each field to help support decision making.
Have you ever populated a record in NetSuite only to get half way through and the page refreshes, resulting in the loss of data previously entered? This is (unfortunately) a common issue. It is the result of fields not being ordered appropriately on the form.
Some fields will trigger background processes to execute, e.g. customer, vendor, subsidiary, etc. These fields should be populated first so that the background processes can run before the end user populates the remainder of the fields on the form.
Make sure you test this process and confirm the fields are in a logical order, otherwise your end users will have to remember to populate the fields in a specific order to avoid repeating data entry.
Ideally, the “Form” field on each custom form will have its display type set to “Inline Text” or the field will be hidden from the form altogether. In some cases, you may need your end users to select a specific form for one use case and a different form for another, but for the most part users should be interacting with a single form per record type.
As such, the “Form” field should not be edited by the user. To drive the required end user behavior, you should lock down each user role to use specific custom forms. This will ensure consistency for your end users and give them one less field to populate.
Over time, you will naturally add new custom forms to your NetSuite environment. If user roles are not locked down to specific forms, all new custom forms created will be automatically available to your users. This could be confusing for them. In addition, you want to avoid having your end users select the “standard” form, which includes the out of the box format with all custom fields— not ideal for end users to interact with.
When creating custom forms and locking them down to specific user roles, be intentional on the form each role should engage with, e.g. create custom forms for each subsidiary or region or another business segment.
NetSuite allows you to link transaction forms, so that when a user transforms one transaction into another (e.g. sales order to invoice), the system will dictate the form used on the transformed record (invoice record per the example).
This can be especially useful for NetSuite customers who use different sales order forms for different selling models, e.g. software vs services. When the “software” sales order is selected and transformed into an invoice, the system will automatically select the corresponding “software” invoice, assuming it has been set on the “Linked Forms” tab on the custom sales order form.
Salto Tip: In Mistake #4, we discussed locking down forms to specific roles. Note that if a user role is restricted to a specific custom form, the user role preference overrides the form selected on the “Linked Forms” subtab.
Creating new subtabs available on transaction and entity record types is a great way to group custom fields that should be separated from other fields on the form. Perhaps on the customer record you are tracking certain attributes for the business reporting and those attributes should all be populated at the same time; you could create a new subtab entitled “Business Reporting” and include all the appropriate fields under that subtab.
Salto Tip: The first subtab (the leftmost subtab) is important as it will be the first subtab displayed on the page and doesn’t require an additional click to navigate. As such, it should include the most referenced data points on that record—not necessarily the default subtab. Also consider the impact of sublists. Sublists referencing vast amounts of data will take longer to load in the user interface, so you probably don’t want to set a subtab with such a sublist as the default.
While sublists that reference large data volumes can impact the system performance when loading a record, they can be very helpful. They allow users to quickly access related records and thereby navigate the NetSuite platform more efficiently. NetSuite provides some useful sublists out of the box, but consider creating your own, so that they only display the required data points. If the user is able to see all of the data points needed without having to navigate to the related record, that will save them time.
Without clearly defined sublists, users will have to navigate to multiple records in order to obtain the information that they need. This is one of the reasons we end up with so many NetSuite tabs open in our browser at any given time!
Customizing NetSuite forms to meet the needs of your end users will take a significant amount of time—especially if you are enhancing all forms at the same time. Migrating these changes manually from one NetSuite environment (Sandbox) to another (Production) can be painful, not to mention the significant risk there is of human error given the large volume of small changes.
NetSuite Administrators and Developers have a number of options that support migrating custom forms between environments. Out of the box, NetSuite offers SuiteBundler, Copy to Account and SuiteCloud Development Framework (SDF). There are benefits and drawbacks to each of these options. I have found that the more technical folks lean toward SDF to migrate changes, but there can be challenges with record dependencies when migrating custom forms.
These NetSuite solutions help to avoid manual migration efforts. However, there are also other solutions to consider. One such alternative is Salto. The Salto SuiteApp helps NetSuite Administrators and Developers manage their NetSuite customizations, including custom forms, in a more automated way by speeding up the deployment process. Salto can easily compare NetSuite environments to help identify any discrepancies between them, as well as confirm record dependencies. This can be invaluable when migrating custom forms, because the probability of having record dependencies is much higher!
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 customizing forms.
One of the many benefits of implementing NetSuite is the ability to customize the system to meet your specific business needs. That should include how your end users engage with the system. Take the time to customize each form that a user may interact with, so they can operate effectively and efficiently when navigating the tool.
Consider using the above best practices as a checklist when going through your own NetSuite form customization initiative. If you can execute on each of these points you will be setting up your end users for success and they will reciprocate by sharing positive experiences when interacting with NetSuite.