SuiteApps and Sandbox Accounts

NetSuite sandbox accounts provide areas for the development and testing of bundles without disrupting day-to-day business activities 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 provide:

a safe place to test customizations to NetSuite, such as bundles
a realistic starting point for development, because they initially mirror your production account, including its configuration, data, and customization

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

Note:

Support for bundle operations varies across the different types of NetSuite accounts, including sandbox accounts. 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 are developing or testing bundles, it is important that you account for these limitations in the sandbox account. For a complete list of limitations, see Features Available for Testing in a Sandbox.

Also, be aware of the following:

You cannot deprecate a bundle that has been created in a sandbox account. However, if a bundle that has been installed in a sandbox account has been deprecated, the bundle in the sandbox account can be updated with the replacement bundle.
The Copy action is not 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 is not available in sandbox accounts. If you want to install a bundle from a sandbox account to another account where you have administrator access, you will need to go to that target account to search for and install the bundle.
You should not check the Hide In SuiteBundle box for a script to be included in a bundle developed in sandbox. 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.
You should not lock bundle objects to be included in a bundle developed in sandbox. Locking objects in the source sandbox account for the bundle can eventually lead to the objects being locked in that account. After the bundle is installed in production and the sandbox account is later refreshed, the production account settings for locked objects are copied to the sandbox account. 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