SuiteApps and Sandbox Accounts

NetSuite sandbox accounts let you develop and test bundles without disrupting your day-to-day business in your NetSuite production account. You can use one or more sandbox accounts for development and testing of your own bundles as well as for testing bundles from external sources such as independent software vendors (ISVs).

Sandbox accounts offer:

a safe place to test customizations to NetSuite, such as bundles
a realistic starting point for development, since they start out as a copy of your production account, including its setup, data, and customizations

For general information about using sandbox accounts, see NetSuite Sandbox. The NetSuite Development account is another option besides Sandbox. For details, see The Development Account, NetSuite Development Accounts, and the SuiteApp Development Process with SuiteBundler.

Note:

Support for bundle operations varies between different types of NetSuite accounts, including sandboxes. See Bundle Support Across Account Types.

Sandbox Bundle Deployment Models

Review the following for brief descriptions of sandbox bundle deployment models:

Limitations for Bundles in Sandbox Accounts

Some features are limited in their functionality in sandbox accounts, particularly features related to payroll and credit card processing. When you’re developing or testing bundles, make sure you keep these sandbox limitations in mind. For a complete list of limitations, see Features Available for Testing in a Sandbox.

Also, keep in mind:

You can’t deprecate a bundle created in a sandbox account. But if a bundle installed in a sandbox is deprecated, you can update it with the replacement bundle.
The Copy action isn’t supported in sandbox accounts.
Unlike managed bundles installed in production accounts, managed bundles installed in sandbox accounts must be updated manually. For more information about managed bundles, see Managed Bundles Overview.
The Push action isn’t available in sandbox accounts. If you want to install a bundle from a sandbox to another account where you’re an administrator, you’ll need to go to that target account to search for and install the bundle.
Don’t check the Hide In SuiteBundle box for a script you want to include in a sandbox-developed bundle. Checking this box for a script in the source sandbox account for the bundle can eventually lead to the script being hidden in that account. After the bundle is installed in production and the sandbox account is later refreshed, the production account setting for this option is copied to the sandbox account. This copy causes the Hide in SuiteBundle box to be checked and disabled in the source sandbox account, preventing bundle developers from accessing the script. For information about this option, see Protecting Your Bundled Server SuiteScripts.
Don’t lock bundle objects you want to include in a sandbox-developed bundle. Locking objects in the source sandbox account for the bundle can eventually lead to the objects being locked in that account. After you install the bundle in production and refresh the sandbox, the production settings for locked objects are copied to the sandbox. This copy causes the objects to be locked in the source sandbox account, with their lock options disabled, preventing bundle developers from editing these objects. For information about setting lock preferences, see Locking Objects in Customization Bundles.
Support for bundle operations varies across the different types of NetSuite accounts, including sandbox accounts. See Bundle Support Across Account Types.

Warning:

Users are strongly cautioned NOT to rebundle objects that are installed in sandbox from other bundles. If such objects are rebundled, users are also cautioned not to install these bundles in production. Installing bundles with rebundled sandbox objects in a production account has a particularly detrimental impact on SuiteApps, including managed bundles from NetSuite or partner-bundled solutions. These production rebundles can result in an unexpected state of the bundle and account data, and actions to resolve such a state may result in data loss. Users can reduce the risk of such rebundling unintentionally occurring by avoiding the use of the Bundle All option. Manually selecting components ensures that all components are not added by default.

Specialized Features for Sandbox Bundle Development

Sandbox bundle development involves issues that you do not encounter for bundles installed from an external (ISV) account into your production account. Because your sandbox account is a copy of your production account, the objects included in a bundle created in sandbox are likely to also exist in production. Because of this copying, bundle updates from sandbox to production usually involve significantly more object conflicts than updates of ISV bundles. Refreshes of a sandbox account can result in overwriting of bundle objects and loss of data, due to changes made to bundle objects in production. See Sandbox Refresh Impact on Bundles.

SuiteBundler includes the following features that address unique issues for bundles developed in sandbox accounts:

Sandbox Bundle Deployment Models

Limitations for Bundles in Sandbox Accounts

Specialized Features for Sandbox Bundle Development

Related Topics