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 supplements 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 can be challenging, especially when it comes to entry and transaction forms. 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 of the various challenges associated with each approach for automated deployment of NetSuite form customizations, as we will see shortly.

Manually replicating customizations during deployment gets the job done, but it can also be time-consuming and error-prone. In this article, we'll lay out all of your options, exploring both the various deployment options available in NetSuite along with a non-native option you can also look into. You'll learn how to assess which options will work for you, as well as when the conventional wisdom of manually replicating customizations 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.
‍

You can see in the screenshot that several of our layout customizations were reset—which is what leads many NetSuite developers to recommend manual deployment. However, what you decide will most likely depend on how many customizations you have, as well as how comfortable you are replicating all of them manually. There are, of course, pros and cons to either approach.

‍

Option 2: Customization Deployment via SDF

The SuiteCloud Development Framework (SDF) is a developer-oriented framework introduced by NetSuite to help 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. This makes SDF a great option! However, when considering using SDF, keep these things in mind:

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—which is great news for developers, but also means that non-developers may find it more challenging.
   ‍
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 can be verbose and/or cryptic, which sometimes makes it difficult to pinpoint and solve the problem.

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. 

For many, the fact that layout changes are preserved with SDF may make it a more appealing option than either Bundler or manual deployment. However, as mentioned earlier, non-developers may have a harder time with SDF, which is something to keep in mind. Indeed, the process is somewhat involved, even for developers. Here’s an illustration of the commands (in VS Code) required to realize a typical deployment using SDF. Note that this assumes 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.

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.

The challenges to look out for when Copy to Account are similar to those of SDF. You should also keep the following in mind:

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. Compared to SDF, Copy to Account may have a tougher time with complex customizations.
   ‍
3. With Copy to Account, you're limited to one customization at a time. If you have a high number of customizations to deploy, this can get to be a long process.

For illustration purposes, the following clip demonstrates how I successfully deployed our basic SO form customization via Copy to Account. If your customizations are very complex, though, you may want to consider using one of the other options.

‍

‍

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 supplements the native NetSuite options by leveraging not just SDF but NetSuite’s SOAP and REST APIs to realize greater functionality.

A few examples of how Salto can enhance your NetSuite experience:

• 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, which can be challenging with 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, which is highly beneficial to NetSuite professionals.

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 also being easy for non-developers to use, too.

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.
• Better 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:

• More challenging for non-developers
• Does not fully preserve form layout.
• Can be hard to debug and sometimes produces 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 challenges

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 an easier deployment experience 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.