SuiteCloud Developer key terms

The unique identifier for a NetSuite environment, used in URLs, authentication headers, and SuiteScript context. Sandbox and production accounts have different IDs, so scripts and integrations must resolve it at runtime rather than hard-coding it.

A copy of a production NetSuite account used for testing customizations, scripts, and integrations before release. Sandboxes refresh from production, so work saved only in a sandbox is overwritten unless it is deployed through a bundle or SDF project.

Customizations made directly in an account, such as custom fields, forms, and scripts, rather than packaged in a distributable bundle. They travel with sandbox refreshes and are managed through customization records and object IDs.

A packaged application distributed through the SuiteApp marketplace or a private bundle. It installs as a unit with its own objects, scripts, and permissions, and can be updated or uninstalled without manually recreating each component.

A packaged collection of customization objects and scripts that can be installed into other accounts. Bundles carry version numbers and lock certain objects, so the provider controls updates while the installing account controls permissions and preferences.

A development framework that represents account customizations as files in a project on a local machine. Developers validate, deploy, and compare projects using the SuiteCloud CLI or IDE tools instead of clicking through the UI.

An SDF project type that holds account-level customizations such as custom objects, scripts, and permissions, and deploys them into a target account. It is the most common project type for moving customizations between environments.

A command-line tool for SDF workflows, offering commands to set up projects, validate, deploy, import, and list objects. It requires a project configuration file and authentication against a specific account and role.

The SDF project file that declares the project type, framework version, and which object types the project manages. Objects not listed in the manifest are ignored during import and deploy operations.

The SDF file that lists the specific objects to deploy, each with a script ID and an action such as add, update, or delete. It scopes a deployment to a subset of the project rather than the whole project.

The unique identifier assigned to a custom object, script, or field, prefixed by the account's customization ID. Scripts reference objects by this ID, and SDF files must match it exactly for deployment to succeed.

A user-defined table for storing data that does not fit standard records. It supports custom fields, subtabs, permissions, and parent-child relationships, and can be accessed in SuiteScript like any standard record type.

The definition of a custom record, including its name, ID, ownership, permissions, and whether it appears in menus. Individual custom records are instances of this type, and scripts load and create them using the type's ID.

An administrator-defined field added to standard or custom records, forms, and transactions. It has a data type, applies to selected record types, and is referenced in SuiteScript by its field ID, which includes the customization prefix.

A user-maintained set of values used to populate a dropdown or multi-select field. Custom lists keep option values consistent across records and can be updated without editing each field definition.

A configurable classification dimension that can be applied to transactions and records, similar to department or class. Segments support filtering, reporting, and permissions, and appear as fields whose IDs follow a segment naming pattern.

Rules on a custom field that automatically populate its value from a source record or restrict selectable values using filter criteria. They reduce manual entry and keep related records consistent.

A named script library loaded with the require function, such as N/record or N/search. Modules expose APIs and constants, and the version suffix in the require path determines which API version the script uses.

The AMD-style wrapper used by SuiteScript 2.x scripts to declare dependencies and export an entry point object. Dependencies are listed as an array and injected as parameters into the callback.

A script type whose exported functions NetSuite calls in response to events, such as User Event, Client, Scheduled, RESTlet, Suitelet, or Map/Reduce. Each type has a defined set of function names and parameters.

A server-side script that runs before load, before submit, and after submit on record create, edit, delete, approve, and similar actions. It can validate data, set field values, and trigger related processing.

A browser-side script attached to a form that responds to field changes, page initialization, saving, and button clicks. It provides immediate feedback but must validate critical logic on the server because client code is not trusted.

A server-side script that runs on a defined schedule or on demand, processing data in batches. It uses a script parameter and a deployment record to control timing, and can reschedule itself or submit follow-up deployments.

A server-side script designed for large data volumes by splitting work into a map phase, optional shuffle and reduce phases, and a summarize phase. NetSuite manages parallelism and governance across stages.

A server-side script that exposes custom logic over HTTP for external systems. It receives request parameters and body, returns JSON or text, and requires an authentication method and a deployment with an external URL.

A server-side script that renders a custom page or handles a form submission inside NetSuite. It can display HTML, build forms, and be linked from menus, and it runs with the permissions of the user who opens it.

The object returned by loading or creating a record in SuiteScript, exposing getValue, setValue, save, and sublist methods. Changes are held in memory until save is called, and field IDs must match the record definition.

A line-item section of a record, such as items on a sales order or addresses on a customer. SuiteScript provides methods to select, insert, update, and remove lines, and each sublist has an internal ID.

A SuiteScript module for querying records with filters, columns, and result handling. Searches can be saved, run ad hoc, or chained, and results expose values and joined fields for related records.

A stored query definition with criteria, results columns, and audience settings. It can be run in the UI or loaded and executed from SuiteScript, and its internal ID is used to reference it in code.

The usage limits NetSuite enforces on script execution, measured in units, with thresholds that trigger warnings and eventually terminate the script. Developers monitor governance remaining and design scripts to stay within limits.

A record that controls where and for whom a script runs, including status, audience, roles, and schedule. A single script can have multiple deployments with different settings.

A browser-based tool for stepping through server-side and client-side SuiteScript, setting breakpoints, and inspecting variables. It requires a deployment in testing status and works within the account's script limits.

An authentication method for integrations that uses client credentials and tokens instead of user passwords. NetSuite supports authorization code and client credentials flows, and tokens are tied to a specific user and role.

An account record that registers an external application, storing its client ID and secret and controlling which authentication methods and permissions it may use. It is required before token-based integrations can authenticate.

NetSuite's standards-based REST API for creating, reading, updating, and deleting records and running queries. Requests use OAuth authentication and return JSON, and the API is versioned independently of SuiteScript.

NetSuite's SOAP-based API for record operations, searches, and metadata. It uses WSDL definitions and token or user credentials, and remains common in older integrations that predate REST.

An integration pattern where requests are queued and processed later rather than answered immediately, often using scheduled scripts, Map/Reduce, or external queues. It improves reliability and handles volume without blocking the caller.