NetSuite Administrator cheat sheet

Account customization vs. company-wide: features enabled under Enable Features apply to the whole account; custom fields, forms, and records must be set to a specific subsidiary, role, or department via the Applies To subtab to limit scope.

Release Preview: sandbox accounts receive the new release roughly one week before production; use Release Preview to test upgrades, then refresh the sandbox from production after the production upgrade completes.

Sandbox refresh copies production data into the sandbox and overwrites sandbox changes; integrations and email are disabled in sandboxes, and SuiteScript deployment must be re-checked after each refresh.

Accounting Periods: locking a period prevents posting to it; closing is a separate step. A closed period can only be reopened by a user with the period-close permission, and each reopen is logged in the system notes.

Company preferences: negative inventory, multi-location inventory, and multi-currency are irreversible once transactions exist; enabling them after go-live requires data cleanup and NetSuite approval in most cases.

Role-based feature gating: a feature enabled at the account level is still invisible to a user whose role lacks the corresponding permission; both the feature toggle and the role permission must align.

Transaction numbering: auto-generated document numbers follow the sequence set on the transaction record type; manual override is allowed only if the Allow Override permission is granted on the role.

Tax and nexus: tax schedules, nexus, and tax codes are configured per subsidiary; SuiteTax changes the model from legacy tax to a unified engine and cannot be mixed with legacy tax codes on the same transaction.

Role hierarchy: a user can hold multiple roles; effective permissions are the union of all assigned roles, so a broad role can override a narrow one. Remove unused roles rather than layering exceptions.

Permission levels: None, View, Create, Edit, Full. Full includes delete and is required for record deletion; View does not permit editing even on records the user created.

Global permissions vs. record-level: a permission like Lists > Employees > View applies account-wide, while subsidiary restrictions on the role limit which records are visible.

Two-factor authentication: required for administrator roles by default; TBA (token-based authentication) is the recommended method for integrations and bypasses interactive login.

SSO and SAML: configure identity provider settings under Setup > Integration > SAML Single Sign-On; map IdP attributes to NetSuite user fields, and keep a break-glass admin with password login.

Role restrictions: IP address restrictions, department/subsidiary/location restrictions, and time-based restrictions each narrow the role's effective access; a restriction on any assigned role can block access unexpectedly.

Employee record vs. user: the employee record holds HR data; the user record holds login credentials and roles. Deactivating the employee does not automatically deactivate the user.

Audit trail: Login Audit Trail records successful and failed logins; System Notes on records capture field-level changes with user, date, and old/new values. Export these for access reviews.

Custom record types: define fields, then attach forms and permissions per role. Custom record entries are searchable only if the record type has at least one searchable field and the role has permission.

Workflow states: each state has entry/exit conditions; transitions are triggered by button, field change, or scheduled. A workflow can be initiated on create, edit, or scheduled; the initiation is fixed once saved, so plan before deploying.

Workflow vs. SuiteScript: workflows are declarative and auditable but limited; SuiteScript handles complex logic. A workflow action can call a script via a workflow action script.

SuiteScript deployment: each script deployment specifies status (Testing, Released, Scheduled), audience (roles, subsidiaries, departments), and log level. A script in Testing runs only for the deployer.

Governance: each script execution has a usage limit (points) that resets per execution; exceeding it throws SSS_USAGE_LIMIT_EXCEEDED. Use map/reduce for large datasets to stay within limits.

Script types: User Event (before/after load, submit, delete), Client (pageInit, fieldChanged, saveRecord), Scheduled, Map/Reduce, RESTlet, Suitelet, Portlet, Workflow Action. Client scripts run in the browser and cannot use server-only modules.

Bundle deployment: install bundles in a sandbox first; after install, review the bundle's objects for conflicts with existing customizations, and lock objects you do not want overwritten.

Version control: use SuiteScript 2.1 for new scripts; 1.0 is legacy. Store scripts in the File Cabinet with a folder structure and deploy via the script record, not by editing the file in place.

CSV import: use the Import Assistant; map fields, set the external ID for upsert behavior, and run in preview mode first. Imports over the row limit must be split into multiple files.

External IDs: set on records and lines to enable idempotent updates; a record with a matching external ID is updated rather than duplicated on re-import.

SuiteAnalytics Workbook vs. saved search: workbooks support pivots, charts, and joined datasets; saved searches are faster for simple lists and can be scheduled for email delivery.

Saved search results are limited by role permissions and subsidiary restrictions; a scheduled search email runs as the owner, so a deactivated owner breaks the schedule.

RESTlet and SuiteTalk: RESTlets are custom endpoints; SuiteTalk (SOAP/REST web services) uses standard record operations. Both require token-based authentication for server-to-server integrations.

Integration concurrency: NetSuite enforces a concurrent request limit per account; batch integrations should throttle and handle 429/limit errors with retry and backoff.

Data migration order: import reference data (subsidiaries, departments, classes, items, customers) before transactions; transactions reference these records by internal or external ID.

Report customization: financial reports use layouts and column sets; a report's data is governed by the reporting period and the role's subsidiary access, so the same report can show different totals per user.

Account customization vs. company-wide: features enabled under Enable Features apply to the whole account; custom fields, forms, and records must be set to a specific subsidiary, role, or department via the Applies To subtab to limit scope.

Release Preview: sandbox accounts receive the new release roughly one week before production; use Release Preview to test upgrades, then refresh the sandbox from production after the production upgrade completes.

Sandbox refresh copies production data into the sandbox and overwrites sandbox changes; integrations and email are disabled in sandboxes, and SuiteScript deployment must be re-checked after each refresh.

Accounting Periods: locking a period prevents posting to it; closing is a separate step. A closed period can only be reopened by a user with the period-close permission, and each reopen is logged in the system notes.

Company preferences: negative inventory, multi-location inventory, and multi-currency are irreversible once transactions exist; enabling them after go-live requires data cleanup and NetSuite approval in most cases.

Role-based feature gating: a feature enabled at the account level is still invisible to a user whose role lacks the corresponding permission; both the feature toggle and the role permission must align.

Transaction numbering: auto-generated document numbers follow the sequence set on the transaction record type; manual override is allowed only if the Allow Override permission is granted on the role.

Tax and nexus: tax schedules, nexus, and tax codes are configured per subsidiary; SuiteTax changes the model from legacy tax to a unified engine and cannot be mixed with legacy tax codes on the same transaction.

Role hierarchy: a user can hold multiple roles; effective permissions are the union of all assigned roles, so a broad role can override a narrow one. Remove unused roles rather than layering exceptions.

Permission levels: None, View, Create, Edit, Full. Full includes delete and is required for record deletion; View does not permit editing even on records the user created.

Global permissions vs. record-level: a permission like Lists > Employees > View applies account-wide, while subsidiary restrictions on the role limit which records are visible.

Two-factor authentication: required for administrator roles by default; TBA (token-based authentication) is the recommended method for integrations and bypasses interactive login.

SSO and SAML: configure identity provider settings under Setup > Integration > SAML Single Sign-On; map IdP attributes to NetSuite user fields, and keep a break-glass admin with password login.

Role restrictions: IP address restrictions, department/subsidiary/location restrictions, and time-based restrictions each narrow the role's effective access; a restriction on any assigned role can block access unexpectedly.

Employee record vs. user: the employee record holds HR data; the user record holds login credentials and roles. Deactivating the employee does not automatically deactivate the user.

Audit trail: Login Audit Trail records successful and failed logins; System Notes on records capture field-level changes with user, date, and old/new values. Export these for access reviews.

Custom record types: define fields, then attach forms and permissions per role. Custom record entries are searchable only if the record type has at least one searchable field and the role has permission.

Workflow states: each state has entry/exit conditions; transitions are triggered by button, field change, or scheduled. A workflow can be initiated on create, edit, or scheduled; the initiation is fixed once saved, so plan before deploying.

Workflow vs. SuiteScript: workflows are declarative and auditable but limited; SuiteScript handles complex logic. A workflow action can call a script via a workflow action script.

SuiteScript deployment: each script deployment specifies status (Testing, Released, Scheduled), audience (roles, subsidiaries, departments), and log level. A script in Testing runs only for the deployer.

Governance: each script execution has a usage limit (points) that resets per execution; exceeding it throws SSS_USAGE_LIMIT_EXCEEDED. Use map/reduce for large datasets to stay within limits.

Script types: User Event (before/after load, submit, delete), Client (pageInit, fieldChanged, saveRecord), Scheduled, Map/Reduce, RESTlet, Suitelet, Portlet, Workflow Action. Client scripts run in the browser and cannot use server-only modules.

Bundle deployment: install bundles in a sandbox first; after install, review the bundle's objects for conflicts with existing customizations, and lock objects you do not want overwritten.

Version control: use SuiteScript 2.1 for new scripts; 1.0 is legacy. Store scripts in the File Cabinet with a folder structure and deploy via the script record, not by editing the file in place.

CSV import: use the Import Assistant; map fields, set the external ID for upsert behavior, and run in preview mode first. Imports over the row limit must be split into multiple files.

External IDs: set on records and lines to enable idempotent updates; a record with a matching external ID is updated rather than duplicated on re-import.

SuiteAnalytics Workbook vs. saved search: workbooks support pivots, charts, and joined datasets; saved searches are faster for simple lists and can be scheduled for email delivery.

Saved search results are limited by role permissions and subsidiary restrictions; a scheduled search email runs as the owner, so a deactivated owner breaks the schedule.

RESTlet and SuiteTalk: RESTlets are custom endpoints; SuiteTalk (SOAP/REST web services) uses standard record operations. Both require token-based authentication for server-to-server integrations.

Integration concurrency: NetSuite enforces a concurrent request limit per account; batch integrations should throttle and handle 429/limit errors with retry and backoff.

Data migration order: import reference data (subsidiaries, departments, classes, items, customers) before transactions; transactions reference these records by internal or external ID.

Report customization: financial reports use layouts and column sets; a report's data is governed by the reporting period and the role's subsidiary access, so the same report can show different totals per user.