If you are a NetSuite administrator or developer, this post will help you avoid a major pain point that others have encountered when managing changes between their NetSuite sandbox and production environments.

‍

‍

Losing new configurations after your NetSuite sandbox is refreshed from production

Many customers that we work with develop in their shared sandbox environment, and then deploy their work to production. Every once in a while, they refresh the sandbox in order to make sure that it is aligned with production. This is important in order to make sure that the development process is based on the most up to date setup. But when a shared sandbox is refreshed from production, all of a sudden all the features that were applied to the sandbox but weren't applied to production are lost. The obvious solution is to back up your work before refreshing the sandbox. But how do you do that?

Through our conversations with NetSuite developers, we learned about many creative ways used to back up sandbox data, from taking screenshots of customizations to copying the SuiteScripts content and re-creating them after the refresh. However, as most of these methods are manual, time-consuming, and prone to error, they can lead to a decrease in the amount of refreshes performed. Many developers were still looking for a smoother way to keep their sandboxes aligned with production.

‍

A new approach to optimize your work on NetSuite development environments

I’m part of the engineering team here at Salto, where we’re building a solution that enables business applications developers and admins to manage and configure their various SaaS applications using code. We created an intuitive structured language that enables text search, re-use of configs and in-line documentation, and added a built-in Git client that allows users to easily audit and document changes, debug and revert to previous versions. This approach enables us to make sure that you can maintain different versions of your sandbox, track changes, compare versions, deploy and, if needed, revert back to prior versions.

‍

Here is how it's actually done in Salto's workspace*:

‍

1. Fetch

Salto's Fetch operation connects to the selected NetSuite environment via its API, downloads its current configuration state, and updates the NaCl files accordingly. By clicking on the Fetch button, your configuration is fetched from the sandbox account right before you trigger the sandbox refresh. This way Salto will hold the most updated state of the sandbox account configurations and will be able to restore it right after the refresh is done.

‍

‍

2. Push to Git

The Push to Git operation wraps the changes into a single commit, lets you edit the commit message title and body, and immediately pushes it to Git. The push is made in order to keep the version control updated with every step that is taken in the account, so that you can also revert to a certain point in time or just track the changes that were made throughout time.

‍

‍

3. Refresh sandbox via NetSuite UI

Next, go into your NetSuite instance and request a refresh. If you need a “refresher” (sorry, couldn’t resist), here are the steps you’ll need to follow: 

• Log in to the production account that’s associated with the sandbox you want to refresh
• Navigate to Setup > Company > Sandbox Accounts
• Select which users should have access to the sandbox after the refresh 
• If applicable, select the account you want to copy data from for this sandbox refresh (Note: If you’re on NetSuite’s standard service tier, your source account will always be your production account by default)
• Click Refresh Sandbox
• Click Okay in the confirmation pop-up 
• You can then monitor your refresh status on the Sandbox Accounts page
• When the new copy of your sandbox is ready, navigate to the Sandbox Accounts page and click Activate Sandbox

‍

4. Fetch state only

Fetch your configuration from the sandbox account right after the sandbox refresh is done with the State Only flag. This way Salto will be updated with the refreshed state of the sandbox while not applying it to the NaCl files. This approach will enable Salto to calculate the differences between the desired configuration that is represented in the NaCl files and the current state of the account.

‍

‍

‍

5. Deploy

Deploy your configuration to the sandbox account to have the same configuration as it had before the refresh.

* Prior to this step you can edit and remove changes that you don't like to deploy back to the sandbox account.

‍

‍

6. Push to Git

As mentioned earlier, the push to Git is meant to make sure that everything is documented so we can audit the changes in the account, and potentially revert back to an older version.

To summarize, Salto enables you to maintain different versions of the configuration, compare and find the differences between them and then deploy. We all know how frustrating developing across environments can sometimes be. We live and breathe it, which is why we wanted to make sure that you will never lose the work you've done in a Netsuite sandbox again.
‍

* The screenshots above were taken from the workspace of our Enterprise SaaS product. Everything I showed is also available in our free open source product