Understand your options for customization deployment between NetSuite accounts

NetSuite offers three out-of-the-box automated options for deploying customizations from one account (e.g. Sandbox) to another (e.g. Production). In this article, you will learn the strengths and weaknesses of each approach, allowing you to choose the option that is best suited for your situation. Furthermore, we will present a novel approach that supersedes NetSuite’s native offerings. 

This article is relevant for NetSuite (super-)users, administrators, developers, consultants (functional or technical), and anyone else involved in account customization and deployment of such customizations.

‍

‍

Challenge

If you have been involved in a non-trivial NetSuite cutover, you probably know that deploying customizations from one environment to another is hardly ever a walk in the park. Entry and transaction forms typically produce the most headache. For illustration, we will consider a form that is used by pretty much every business - the Sales Order (SO) form. 

The typical process is that you customize artifacts (in our case, the SO form) in Sandbox. After you have gone through user acceptance testing and adjusted the form layout to meet their specifications, it is time to deploy and you wonder how best to get these beautifully customized forms over to Production. Most seasoned NetSuite professionals (especially non-developers) will tell you straight up that your best bet is to move the forms over manually and redo the customizations in Production. This is because, as we will see shortly, the approaches for automated deployment of NetSuite form customizations all have their shortcomings. 

Understandably, nobody wants to manually replicate customizations during deployment because it is boring, error-prone, and often time-consuming. After reading this article, you’ll be equipped with information to help you assess when this conventional wisdom should be challenged.
‍

Overview of Deployment Options

The NetSuite customization deployment options that we will review in this article are:

1. SuiteBundler
2. SuiteCloud Development Framework
3. Copy to Account
4. Salto.io (non-native)

‍

The Test Sales Order Form

To illustrate the differences between the various deployment approaches, I created a sample SO form with some account-specific custom fields.

Here’s the SO form in Sandbox before layout customization:
‍

Fields Last Modified Date, Created Date, Customer Balance, and Customer Balance Currency are custom transaction body fields created to meet our imaginary client’s requirements. Notice the duplicate Last Modified Date (2) and Created Date (2) fields. That is because we installed a third-party bundle (Enhanced Sales Center, ID 58416) that contains fields with the same names as the ones that we had created in the account. While there are simple ways to avoid such name conflicts using account prefixes, it is not uncommon for duplication/name conflicts to occur. Even in the absence of duplicate fields, it is common to adjust form layouts to match client preferences. 

Here’s the SO form in Sandbox after the highlighted layout modifications. This is the form as the client wants it in Production after deployment:
‍

Let’s go ahead and put the deployment methods to the test to discover which one(s) , if any, would produce an undistorted layout.

‍

Option 1: Customization Deployment via SuiteBundler

SuiteBundler is NetSuite’s legacy deployment approach. You can learn more about this tool by reviewing the official documentation here. The idea is simple: In the source environment (e.g. Sandbox), you use the point-and-click bundler wizard to include the desired customizations in an account customization bundle. NetSuite will automatically determine the dependencies and add them to the bundle. A bundle is private by default which means it can only be deployed to other environments (i.e. Production or another Sandbox) associated with the same account. However, a bundle’s visibility can be adjusted to make it Public (accessible to everyone) or Shared (accessible to a list of specified accounts).

In the target environment, you find and install the bundle. NetSuite does the rest in the background and once the bundle is installed, your customizations would be added to the target account.

The following clip illustrates the process of deploying our SO form customization via SuiteBundler:

‍

‍

While SuiteBundler is easy to use and intuitive, it has significant drawbacks:

1. While NetSuite continues to support SuiteBundler it will not be updated with new features as per the official notice here. Instead, users are encouraged to leverage the two other tools that we will discuss shortly - Copy to Account and SuiteCloud Development Framework.
   ‍
2. SuiteBundler offers no control over which dependencies are deployed. Every dependency is pulled into the bundle, often resulting in a bloated bundle and the risk of overriding changes in the target environment.
   ‍
3. SuiteBundler does not support several customization types for example Email Templates, SuiteAnalytics Datasets, and Workbooks.
   
   Salto Suite Tip: There is a trick to bundling Email Templates by adding them to an email step in a dummy workflow and deploying the workflow. Although the Email Templates will not be listed as bundle components, they will still be deployed!
   ‍
4. SuiteBundler does not preserve form customizations. 

Here’s our SO form after deployment to Production via bundler.
‍

Notice that most of our layout customizations were reset/lost. What is more annoying is the fact that after manually fixing the form in Production and then performing a subsequent bundle installation that referenced the form, the form got reset again!

Now you probably understand where the conventional wisdom of manual deployment comes from. If you have to redo so much of the work after a bundle deployment, you’re often better off just deploying manually. After years of having bundler as the primary option for deployment, most non-technical users got accustomed to being disappointed and quit trying automated form deployment.

‍

Option 2: Customization Deployment via SDF

The SuiteCloud Development Framework (SDF) is a developer-oriented framework introduced by NetSuite to, among others, solve the deployment challenge. SDF is intended to provide Netsuite developers with tools that facilitate a more streamlined development lifecycle. SDF features a command line interface (CLI) for Node.js and Java as well as IDE integrations for Visual Studio Code and WebStorm (there was also an Eclipse integration which has now been sunset).

NetSuite is actively investing in SDF with additional features being added with every NetSuite bi-annual release since its initial release. While SDF is a step in the right direction, it is not without its limitations, notable among which are:

1. Although SDF supports the deployment of more customization types than SuiteBundler, it still cannot be used to deploy everything. Refer to the official documentation here to see the list of supported customization types.
   ‍
2. SDF is very developer-focused. That is good news for developers but not-so-good news for everyone else. Given that admins/functional users, not developers, are most often involved in deploying customizations such as forms, SDF is simply out-of-reach.
   ‍
3. While SDF does a better job at preserving form layout customizations, it does not produce a replica of the source form.
   ‍
4. SDF errors are often verbose and/or somewhat cryptic. It’s all good until something goes wrong and you have to figure out what it is and how to fix it.

Here’s our SO form after SDF deployment:
‍

Unlike Bundler, all layout changes were preserved by the SDF deployment. However, the highlighted fields which were hidden in the customized form somehow became visible upon deployment. On the positive side, after hiding those fields in Production and redeploying via SDF, the changes were not overridden.  Additionally, unlike Bundler, SDF supports excluding dependencies from a deployment by referencing them as being already present in the target environment in which case they do not get redeployed. 

SDF is a significant improvement above bundler and I assess that most users will gladly accept these results over manual deployment. However, as mentioned earlier, SDF is not suitable for non-developers which makes it hardly useful to the users tasked with cutovers. Even for the developers, the process is somewhat involved. Here’s an illustration of the commands (in VS Code) required to realize a typical deployment using SDF. Note that this assumes that you already have a working SDF setup on your development machine. If not, refer to the official documentation for how to set SDF up.
‍

As illustrated above, you’ll typically need to complete the following steps for a deployment using SDF:

1. Create an SDF project on your local machine.
   ‍
2. Connect or point to the source account (e.g. Sandbox).
   ‍
3. Import the target customization objects (in our case, the SO form) from the source account.
   ‍
4. Add the necessary dependencies to the manifest.xml file and manually decide which ones to be deployed or skipped because they are already in the target account and do not need to be replaced. This requires a bit of dexterity with XML.
   ‍
5. Connect or point to the target account (e.g. Production).
   ‍
6. (Optional but recommended) Validate the deployment and fix any errors.
   ‍
7. Deploy.

Interestingly, when doing the demo deployment in preparation for this article, I mistakenly mixed up my account IDs during SDF setup and ended up deploying the SO form to the source account instead of the target account! 
‍

Obviously, this was a setup error on my part. However, it goes to show the level of care SDF requires. If you are not a developer, I completely understand if you look away from SDF.

NetSuite is aware of this challenge and offers the relatively new “Copy to Account” feature which we investigate next.

‍

Option 3: Customization Deployment via Copy to Account

Copy to Account is SDF “lite”. Think of it as a limited version of SDF with a user interface allowing non-developers to leverage SDF to deploy customizations from one account to another. You can learn more about this feature and how to enable it by reading the official documentation here.

Copy to Account inherits the limitations of SDF. In addition:

1. Copy to Account is not yet available for all customizations supported by SDF. For example, at the time of writing, financial reports cannot be deployed via this approach although they are supported by SDF.
   ‍
2. It may fail where SDF will succeed. Typically, Copy To Account will succumb once customizations become complex. In some cases, the page simply hangs or returns a very generic error that is hard to debug.
   ‍
3. Most importantly, Copy to Account is limited to one customization at a time! This can make it a very laborious process to deploy multiple customizations.

For illustration purposes, the following clip demonstrates how I deployed our SO form customization via Copy to Account. As the customization was pretty basic, the deployment was successful. However, this is not representative of day-to-day experiences with the tool.

‍

‍

I assess that this tool is still in its infancy and will be used/successful for lightly customized elements needing quick deployment. If deployment fails, you’d try another approach rather than trying to resolve the Copy to Account errors as the latter will likely cost you more time.

In terms of the deployed form, it looked exactly like the one deployed using SDF i.e. the two spurious fields became visible post-deployment. But, like SDF, upon fixing the form and performing a subsequent deployment, the fixes were not reverted. This is unsurprising as Copy to Account is SDF with a light user interface on it.

Now that we have explored all native deployment options, let’s consider Salto.io.

‍

Option 4: Customization Deployment via Salto.io

Salto is a framework that aims at bringing the powers of DevOps to business applications like NetSuite, Salesforce, Workato, Zendesk, and Jira. Among other features, Salto supports customization deployment. You can read more about Salto here.

Salto is easy to configure and features an intuitive UI. What’s more, it leverages not just SDF but NetSuite’s SOAP and REST APIs to realize functionality that is not available with SDF (using it's own SuiteApp)

A few examples of how Salto is superior to SDF:

• While SDF is limited to fetching files in the SuiteScripts, Templates & Web Site Hosting Files subdirectories of the File Cabinet, Salto can pull in (and subsequently deploy) all files/folders in the File Cabinet.
  ‍
• Salto supports the deletion of files from the File Cabinet. This solves a well-known limitation of SDF. Salto users can also delete NetSuite custom record types and some standard types.
  ‍
• Salto supports the deployment of data types e.g. Subsidiary, Currency, Department, Account, Location, Items. Thus, entries of these types defined in Sandbox can be deployed to Production via Salto. This overcomes another known limitation of NetSuite’s tools. Note that for some of these data types, e.g. Subsidiaries, CSV import is also not an option. So, without Salto, it’s totally a manual affair.

Going back to our SO form deployment, the following clip illustrates the process within Salto:

‍

‍

The Salto deployment wizard is intuitive and user-friendly. Moreover, the results were identical to the SDF deployment results as Salto currently leverages SDF for this kind of deployment. I’ve reached out to the team to inquire if they can do better i.e. hide the two fields which were not part of the customized form. 

‍

‍

Salto brings the best of SDF and Copy to Account together by supporting the deployment of multiple customizations together while offering the ease of deployment intended by NetSuite’s Copy to Account except with superior UX and better error handling. Salto is thus a tool for developers and non-developers alike.

‍

‍

Summary of Deployment Options

To conclude, let’s review the pros and cons of the various deployment options discussed in this article.
‍

SuiteBundler

Pros:

• User-friendly and intuitive.
• Well-understood as it has been around for a while.
• Superior handling of circular dependencies, conflicts, list entry IDs, etc. than SDF

Cons:

• NetSuite is no longer releasing new features to SuiteBundler.
• SuiteBundler does not preserve form layout.
• Resets form layout on subsequent bundle installations/updates.

When to Use: Consider bundler if you understand its quirks and are not deploying heavily customized transaction or entry forms. Even with complex form customizations, bundler can still be used for the initial form deployment just to get going. However, future updates will need to be done via other methods as bundler will reset the layout.

‍

SDF

Pros:

• Excellent for code deployments and lends itself towards CI/CD operations thanks to the command line interface that is part of the SDK.
• Supports more customization types than bundler.
• Does not reset form layout after the initial deployment.

Cons:

• Not accessible to non-developers and is not very user-friendly.
• Does not fully preserve form layout.
• Hard to debug and sometimes produces annoying warnings (creating a blank SDF project and trying to deploy it might sometimes fail or produce a lot of warnings!).
• Does not support deletion.

‍

When to Use: If you are a developer and primarily deploy source code, SDF is a great option.

‍

Copy to Account

Pros:

• More accessible than SDF and can be used by non-developers.

Cons:

• Not available for some customization types supported by SDF.
• Inherits SDF’s limitations.

When to Use: If you need to do a quick deployment of light customizations, one at a time.

‍

Salto.io

Pros:

• Combines the powers of SDF and Copy to Account into a user-friendly and intuitive tool.
• Accessible to both developers and non-developers.
• Supports all files/folders in File Cabinet.
• Supports file deletion.
• Supports more data types than SDF.

Cons:

• New tool thus has a learning curve (though not a steep one).
• May be limited by underlying tool restrictions. For instance, if SDF fails, Salto will likely fail too for operations where it uses SDF.

When to Use: If you want the best deployment experience currently available and are open to trying out something new.

‍

—

‍

Salto aims at filling a gap in the NetSuite deployment space and so far, my assessment is positive. As I learn more, I’ll publish additional articles highlighting various aspects of the framework that I find interesting. In the meantime, consider signing up for a free Salto account to evaluate the framework and draw your own conclusions.