If you manage Salesforce and NetSuite, I’ll bet you spend a lot of time working on what feels like redundant tasks. Deploying your work from sandboxes to production feels difficult and slow, and whenever you refresh the sandbox, anything anyone was working on there is erased. 

In fact, that sandbox is probably often falling out of sync, which slows production to a crawl. 

That’s why I’m excited to announce Salto’s newest update, which makes it easy to deploy changes with confidence. Specifically, it allows you to push all metadata changes from your Salesforce or NetSuite sandbox into production while preserving any dependencies. It lets you run checks to ensure these changes won’t collide with anything in production, and it lets you selectively deploy or back-promote changes to and from your sandbox to keep it synced.

Let’s explore why we built it, and how it works.

‍

‍

Common challenges that led us to build this feature

Sandboxes in Salesforce and NetSuite serve some useful testing functions, but they aren’t everything you’d need to manage your business system’s full development lifecycle. Moving changes from sandbox to production is often a manual, error-prone process. 

Let’s explore those challenges in each system.

In Salesforce, you can’t move everything you build

If you are deploying with change sets, you’re probably familiar with the following challenges:

1. You have to select one metadata item at a time. But what if you want to select two fields and three email templates? You have to save your work and return to the selection page. Multiply this by every metadata type you plan to deploy, and running a single change set can easily take half an hour.

2. If you are modifying existing metadata, you can't see what that metadata looks like in the target org. You have to log in to both orgs, check the differences manually, and once you deploy, confirm that the intended changes saved successfully. 

3. Deploying Field-Level Security (FLS) for just two fields? You can't deploy just the FLS part of the profile. The entire profile gets overwritten with whatever was in the source org.

4. If you are working with Salesforce CPQ, the CPQ configuration has its entirely own deployment process, which means you’re now supporting two deployment processes. 

5. Change sets don’t allow you to deploy partial profiles, so you must deploy the entire thing. 

6. The sandbox feels fragile and perpetually out of sync with production. If someone updates it to match production or any other source environment, it overwrites everything anyone else was working on.
   ‍

As a result, system admins spend lots of time rebuilding their configurations in production, with all the added potential for human error. You may have built something correctly the first time in the sandbox, but rebuilding it in production might cause you to rush and make mistakes.

‍

In NetSuite, the deployment features are limited and you can't compare environments

Furthermore, you can only push some components to production. Today, the main three ways to move change are NetSuite Bundles, Copy to Account, and SuiteCloud Development Framework (SDF). Each has its own limitations:

1. NetSuite Bundles doesn’t support all components. In many cases, if you promote a change, you’ll have to follow up with additional edits in production. 

2. Bundles automatically include all the dependencies (referenced by), even though you might not want them to, because they’ll override what's in production. 

3. Copy to Account is a bit better than Bundles (it’s supported by SDF), and it covers more components—but still not all components. You also can't promote several changes together. Only one at a time.

4. If you’re a developer, working directly with the SDF CLI gives you the most control. But again, not everything is supported, and deployments may fail because you can’t compare environments before you promote changes.
   ‍

That last problem is relevant to all existing deployment methodologies—you can’t compare the source environment and target environments while making a change. NetSuite may show you whether your component already exists in the target environment, but that’s it, which doesn’t tell you how it’ll clash with other features or rules, and doesn't give you the full context you need.

In addition, in many cases, the deployment fails because the environments are not in sync. Sandbox refresh frequencies are limited. Refreshes also reset the entire sandbox and cause you to lose any partial work. But if system admins resist updating the sandbox because they don’t want to lose their work, it falls out of alignment with other environments and with production. And once it starts to misalign, you have to reset it, because again, you can’t compare environments.

We built Salto to smooth all this out for both Salesforce and NetSuite.

‍

Salto allows you to deploy with confidence—in just a few clicks

Salto lets you compare your environments, see the differences, select the changes you’d like to deploy, preview them and get full visibility to the change impact, and then deploy. Teams no longer have to rely on manual methods or complex tools to promote changes between environments.

‍

Specifically, Salto allows you to:

‍

Deploy everything, or just some things. Deploy whatever you like, including metadata and references. That means you can promote changes to the integration, testing, or production environments. It also means you can back-promote updates from those higher environments back to your sandbox, so it stays in sync.

You can easily compare and align your sandbox to other environments, including production. This allows you to know what’s missing in your sandbox, and if needed, make a fix without refreshing the entire sandbox. 

Detect issues before you deploy. Because Salto has full visibility into your configuration, you can conduct impact analysis to see what will happen if you do deploy. If you’re about to deploy a configuration with missing references, or which will collide with something in production, Salto will tell you. 

Collaborate on changes. Salto gives you a collaborative interface so you can coordinate and work on changes with a global team, without impacting one another. That means, different team members can select which changes to deploy, review the deploy plan together and ensure there are no development conflicts. 

Save work in your sandbox. Just as you can push changes up into production, you can push them down into your sandbox. Salto allows you to save a snapshot of your sandbox, so even after you refresh it, you can reload configurations you were working on, but weren’t finished with. It’s an easy way to save your teammates’ work, but still push yours into production. 

The result of all of this is that you can deploy what you like, forwards and backwards, without having to rebuild or check it manually. Salesforce teams will appreciate that “any data or metadata” includes CPQ data and full profiles (deploy CPQ just as you would any other metadata, so only one workstream!). NetSuite teams will appreciate that you can compare environments and all their dependencies, and deploy all components, even down to email templates.

And both teams will appreciate that their sandboxes will continue to mirror production or other environments, without them losing their work.

‍

Save time, eliminate errors, and avoid redundant rebuilds

In beta, we found Salto users spent far less time deploying a change from sandbox to production. It also reduced the risk of error, as there’s no second opportunity for mistakes when you manually build something again in production.

If you build something correctly in the sandbox, it should go right into production. That’s our philosophy, and it’s part of our master plan to help you master Salesforce and NetSuite.

Questions? Ideas? We’d love to hear about it on Twitter.