If data quality matters to you, you should probably test your NetSuite customizations and configuration changes in a series of sandboxes. As you validate each change, you move it from dev to user testing to production. 

But as any power user knows, doing this is no simple matter. NetSuite’s tools for promoting changes from sandbox accounts to production don’t exactly let you move at the speed of the business. If you’ve ever tried to make one change quickly, or a dozen changes at once, you know the pain.

In this article, I’ll explore ways to make those changes smoother. First, I’ll share ways to do it natively in NetSuite, and then, how you can do it markedly faster using Salto. 

(Note: We love NetSuite! It’s a powerful system. It is the standard. But, the tools available for deploying account customizations haven’t kept up with modern DevOps practices, which is why Salto exists.)

‍

‍

Three native ways to deploy changes: bundles, “copy to account,” and SuiteCloud developer framework (SDF)

‍

‍

1. NetSuite bundles (SuiteBundler)

This NetSuite feature is actually nearing the end of its life according to the company. But at the time of writing, it’s still widely used and worth covering. 

Bundles was the classic way to move components between environments in NetSuite—via a group of changes, or “a bundle.” Only problem is, bundles have never supported some components such as email templates, which you must rebuild separately by hand. It’s worth noting that the list of components that bundles cannot deploy will only continue to grow, because NetSuite will keep innovating and updating other deployment methods, while bundles will remain the same.

Here’s another challenge: One cannot partially deploy a bundle. It’s all or nothing. And if your change references something (is “referenced by”), NetSuite will include that referenced item in your deployment automatically, and you can’t take it out. 

You also can’t compare your bundled components to production, so it’s tough to know precisely what it will change once you deploy. Nor how your new deployments will interact with existing customizations. 

And then there’s the fact that bundles weren’t built with DevOps principles in mind. It was built to allow independent software vendors (ISVs) to make their builds publicly available, so its creators didn’t think about the features necessary for change management and automated deployments. 

That means bundles: 

• Invite human error, just like any point-and-click system
• Don't allow you to manage infrastructure as code
• Are difficult to audit—auditing is proprietary and limited (can’t use Git)
• Don’t let you automate testing

Because of all the aforementioned drawbacks, and the fact it won’t be supported, NetSuite recommends you switch over to “copy to account.” 

2. Copy to account

Unlike bundles, “copy to account” allows you to decide whether or not to include referenced items in a deployment. That’s an improvement. But it’s also designed to only allow you to release one component at a time, so bulk changes are out of the question. (Or very slow, or only for those with a very light social calendar.)

You might want to use this method if:

• The change is simple and you prefer to use an interface

• You want to deploy an ad hoc customization in isolation, right away
• You want to cross-copy customizations between environments for tests, modifications, extensions, debugging, etc.
• You want to preview a customization in the target environment and understand the dependencies
• You’re unaccustomed to working with NetSuite metadata inside an integrated developer environment (IDE), and so can’t use SDF

But of course, “copy to account” also has a few shortcomings:

You can see what some components will look like in production, but not all

NetSuite’s “copy to account” feature lets you preview how things will look in the target environment, like production. The challenge is, it won’t show you what every component looks like—just ones supported by SDF. And sometimes, those unsupported ones are the ones you most want to see, like:

• Most preferences (company, accounting, user)
• Most files in the File Cabinet (with the exception of a few like SuiteScripts and some templates)
• All record data (from customers, orders to subsidiaries, currencies, departments, etc.)

People say it’s not all that user friendly, and sometimes slow

A common complaint is that “copy to account’ works well for simple changes, but not so well for complex ones. As one Reddit user put it, “With simple fields it works well and is fairly quick (not as quick as just creating a bundle containing all customization), but with everything bigger than a simple field, the dependency check runs forever and eventually encounters an error.”

There’s no way to cancel or revert deployments

Once set in motion, you have to wait for that change to process. Be ultra careful when submitting changes.

You can’t move multiple components together

If you’re making lots of changes, “copy to account” is a little less useful than bundles. Even if you create multiple components in the sandbox, you can only move them one at a time. For big or busy teams, that’s a bottleneck. 

‍

3. Suite Development Framework (SDF)

For the technically inclined, there’s SDF. It’s NetSuite’s answer to the DevOps question, and features plenty of documentation. You’ll interface with it through an IDE, or developer command line interface (CLI). (Enough acronyms for you?)

Getting started with SDF is not trivial. For one, learning enough to get to the point where you can repeatedly deploy tested and peer-reviewed code to production takes time. All the documentation assumes you have development experience (nearly all articles begin, “As a developer …”), which, if you have that, is wonderful. But if not, it means you’ll be doing a lot of Googling.

‍

‍

Here are more downsides of working with SDF: 

SDF doesn’t support all objects, or address all data

SDF was built to help with environment management, infrastructure as code, and automated deployments. Any object that’s relevant to that is (or will eventually be) covered. But things like company data are not. That means you sometimes cannot use it to populate test accounts with record data that you’d need to run meaningful user acceptance tests. (If the data exists in production, there are workarounds, but they are time-consuming.)

The validation tool is limiting

The validation tool inspects the SDF project structure and punches out a success or failure validation result. (Read the full list of checks here.) Only, sometimes it overlooks things and successfully validates the project, when things then go on to fail in deployment. This creates unnecessary bottlenecks for automated deployments, and worse, could lead to incomplete deployments within the target account, which means bugs and a bad user experience.

Those are just some of the challenges of working with SDF. Get through all that though, and it provides a foundation for continuous integration and continuous deployment (CI/CD) flows and automated tests. (Though technically, this means you’ll be using XML, which developers famously do not love.)

Or, rather than these three, you can simply select the things you want to push to production with Salto.

Salto is a user-friendlier way to deploy in NetSuite

If you know how Salto works, you know that it extracts all your NetSuite configurations into an interface where you can see and update anything. It’s all the benefits of code, but still human-readable. 

That means it allows you to practice modern DevOps in every way—versioning, reverting, testing, collaborating, and more—and anyone on the team can still read it. That means if you send a snippet to someone on the finance team to say, “Does this look right?” they’ll be able to make sense of it. 

Salto makes promoting changes to production a whole lot easier. 

‍

1. Analyze the impact before you make a change

Salto lets you compare any two environments, so you can compare sandbox and production, and know exactly what’s different. That allows you to analyze the impact of proposed changes. And unlike “copy to account,” it shows you how every element looks.

For speed, you can do this with a quick fetch, where you only fetch selected elements and do not have to wait to fetch everything. And unlike any of the native NetSuite methods, Salto can fetch anything, including your full File Cabinet. 

If you’re ever curious how a change was made, you can look at a history of NetSuite changes to see that a static file was changed, how many times, and who made that change. 

‍

2. Explore all related elements with one click

Salto lets you choose the scope of each deployment, and only deploy the things you want to. So, unlike NetSuite bundles, which forces you to deploy dependent items, you get to choose. 

If you’re curious about that list of related elements, you can simply click a button, and select the ones you want to deploy. (And also ensure you don’t miss any.)

‍

3. Bulk promote changes

Promote as many or as few configuration changes to production as you like. And pause, or revert. It’s that simple.

‍

4. Document, audit, and integrate with Jira

With Salto’s Git and Jira integrations, you can link changes in NetSuite back to tickets in Jira. It creates a full, auditable, SOX-compliant documentation schema. You can follow Jira tickets back to specific changes in NetSuite, or follow changes in NetSuite back to the corresponding rationale in the Jira ticket.

Learn how Riskified implemented NetSuite documentation with Salto.

‍

5. Monitor sensitive configurations

Salto lets you set alerts so you’ll be notified if someone makes changes to sensitive configurations. For example, if someone tries to alter an approval workflow. Get those alerts via Slack or email.

‍

Simplify your deployments

Every method of promoting configuration changes to production in NetSuite has its pros and cons. Bundles is near its end of life, and doesn’t allow you to selectively deploy. “Copy to account” is a little more nimble, but cumbersome if you’re a fast-moving team making frequent or bulk changes. And SDF requires development experience or a developer-level investment in learning the system. 

You can make do with any of these. But with Salto, you can do a lot more than make do.