Controlling Access to Scripts and Custom Modules

You can define the scope of environments (associated NetSuite accounts, sandboxes, and bundles) that may access a script. Access refers to whether the module can be loaded and invoked by another module. Modules are either loaded by the NetSuite system (using entry point modules) or by other modules (as libraries).

Important:

Before deploying a SuiteApp, make sure that you review the module scope. This practice will help you to avoid:

Deploying a SuiteApp that doesn't work as expected because it can’t access a necessary module in another bundle.

Providing wider access than desired to third parties and other accounts.

To set the scope for a script, you must include the appropriate value using the JSDoc tag.

If you do not set the scope, SameAccount applies as the default. For information about adding a JSDoc tag, see SuiteScript 2.x JSDoc Validation.

The following table lists and describes the access control modifiers (supported module scopes) that are available in SuiteScript 2.x:

ModuleScope Value	Description	Access Disallowed When:	Visibility of Source Code	Examples
SameAccount	Limits script access to modules native to the same environment in which the script was created and uploaded. This environment includes the account from which a bundle is installed and can also include the related family of sandbox accounts. For more information about sandbox accounts, see Understanding NetSuite Account Types. A script file that is ‘native’ to the environment is added to an account using an authenticated user session.	A bundled module from a different source account attempts to import the module.	Visible during runtime	Installing a customization from a single sandbox to a production environment that is linked to the same account. Distributing a bundle with private business logic as an ISV (Independent Software Vendor).
TargetAccount	Limits script access to modules native to the same source or target environment as the script. A source environment includes the NetSuite account (and any associated sandboxes and Release Preview accounts) from which a bundle is installed into another account. A target environment includes the NetSuite account (and any associated sandboxes and Release Preview accounts) into which a bundle is installed (whether using Bundle Copy or Bundle Install).	A bundled module that is not native to the target or source account attempts to import the module.	Hidden during runtime	Account administrators distributing private business logic between accounts they control, and the modules in the bundle are needed by other modules created in the target account Distributing a bundle with public APIs intended for import only by modules native to the target account.
Public	Any bundle (native and third party) that is installed in the account can run the script.	The script is not installed in the account.	Hidden during runtime	Customers installing customizations from multiple sandbox accounts to production, where modules from different sandboxes need to load each other. Installing a customization from a development account to a sandbox or production account. Developing open source code.

ModuleScope Value

Description

Access Disallowed When:

Visibility of Source Code

Examples

SameAccount

Limits script access to modules native to the same environment in which the script was created and uploaded.

This environment includes the account from which a bundle is installed and can also include the related family of sandbox accounts. For more information about sandbox accounts, see Understanding NetSuite Account Types.

A script file that is ‘native’ to the environment is added to an account using an authenticated user session.

A bundled module from a different source account attempts to import the module.

Visible during runtime

Installing a customization from a single sandbox to a production environment that is linked to the same account.
Distributing a bundle with private business logic as an ISV (Independent Software Vendor).

TargetAccount

Limits script access to modules native to the same source or target environment as the script.

A source environment includes the NetSuite account (and any associated sandboxes and Release Preview accounts) from which a bundle is installed into another account.

A target environment includes the NetSuite account (and any associated sandboxes and Release Preview accounts) into which a bundle is installed (whether using Bundle Copy or Bundle Install).

A bundled module that is not native to the target or source account attempts to import the module.

Hidden during runtime

Account administrators distributing private business logic between accounts they control, and the modules in the bundle are needed by other modules created in the target account
Distributing a bundle with public APIs intended for import only by modules native to the target account.

Public

Any bundle (native and third party) that is installed in the account can run the script.

The script is not installed in the account.

Hidden during runtime

Customers installing customizations from multiple sandbox accounts to production, where modules from different sandboxes need to load each other.
Installing a customization from a development account to a sandbox or production account.
Developing open source code.

For more information about packaging and distributing bundles (SuiteApps), see SuiteBundler Overview.

Note:

SuiteBundler is still supported, but it will not be updated with any new features.

To take advantage of new features for packaging and distributing customizations, you can use the Copy to Account and SuiteCloud Development (SDF) features instead of SuiteBundler.

Copy to Account is an administrator tool that you can use to copy custom objects between your accounts. The tool can copy one custom object at a time, including dependencies and data. For more information, see Copy to Account.

SuiteCloud Development Framework is a development framework that you can use to create SuiteApps from an integrated development environment (IDE) on your local computer. For more information, see SuiteCloud Development Framework.

NetSuite Development Accounts and Module Scope

Warning:

If you use a NetSuite Development account to work on a module that you intend to distribute or test, you should choose a module scope value rather than accept the default.

Keep in mind that development accounts are limited to 5 users and isolated from production and sandbox accounts. Set the value to Public if other bundles or accounts depend on using a module that is sourced from a development account.

If the default module scope is used on a script in a development account that is packaged into a bundle and installed to production or sandbox accounts, that script will not be accessible to modules installed from other NetSuite accounts. For example, when developers use multiple developer accounts to collaborate on a project, the SameAccount module scope might not be an appropriate access control level. This scope prevents modules installed from different accounts from loading one another.

For more information about development accounts, see The Development Account, NetSuite Development Accounts, and the SuiteApp Development Process with SuiteBundler.

NetSuite Development Accounts and Module Scope

Related Topics