# NetSuite Sandbox Refresh Checklist

> Source: https://netray.co/tools/netsuite-sandbox-refresh-checklist
> Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems.
> Section: Free Tools

## Short answer

A five-stage checklist for refreshing a NetSuite sandbox from production without losing sandbox-only work or sending real emails and payments from the copy.

## Category

netsuite

## Erp

NetSuite

## Audience

- NetSuite administrator
- SuiteCloud developer
- Integration engineer

## Tool

**Kind:** checklist

**Groups:**

#### Before you request the refresh

**Items:**

**Text:** Confirm which sandbox will be refreshed (for example 1234567-sb1 or 1234567-sb2) and from which production account

**Critical:** true

List every script, workflow, custom record and field that exists only in the sandbox and is not yet in production

**Text:** Export work in progress as SDF account customization projects or SuiteApp projects and commit them to source control

**Critical:** true

Record sandbox-only integration records and the applications that use them

**Text:** Record which token-based authentication tokens and OAuth 2.0 client credential (certificate) mappings each integration uses, as these must be set up again

**Critical:** true

Save copies of sandbox-only saved searches, workbooks and test data you want to keep

Note any sandbox-specific SSO, 2FA and user access settings testers rely on

Agree a freeze window with developers, testers and integration owners

#### Requesting the refresh

**Items:**

**Text:** Request the refresh from the production account as an Administrator, on the Sandbox Accounts page under Setup > Company (check the path for your role)

**Critical:** true

Confirm the production source and the sandbox being overwritten before you confirm the request

Tell users that all data and customizations in the sandbox will be replaced by the production copy

Stop integrations and scheduled jobs pointed at the sandbox before the copy starts

Wait for the completion notice before anyone logs in to start testing

#### Immediately after the refresh

**Items:**

**Text:** Check Setup > Company > Email > Email Preferences, Sandbox and Release Preview subtab, so emails go only to the logged-in user, a named list, or nobody

**Critical:** true

**Text:** Review scheduled script and map/reduce deployments and leave only the ones testers need scheduled

**Critical:** true

Disable or repoint outbound integrations, webhooks and RESTlet callers so they do not write to real external systems

**Text:** Re-create or verify integration records and issue new tokens for the integrations that must run in sandbox

**Critical:** true

Re-set inbound SSO and confirm 2FA works for sandbox users

Update account-specific domains in external configs to the sandbox account ID (for example 1234567-sb1.suitetalk.api.netsuite.com)

Update SuiteAnalytics Connect DSNs to the sandbox service host and account ID

**Text:** Set payment processing profiles and gateways to test mode or inactivate them

**Critical:** true

Check that no real customer, vendor or employee notifications can be triggered by workflows

#### Redeploy sandbox work

**Items:**

Redeploy the saved SDF projects with the SuiteCloud CLI and resolve any conflicts with objects now copied from production

Reapply manual sandbox-only customizations that were not in an SDF project

Restore sandbox-only saved searches and test data

Run your data masking routine on customer, employee and pricing data if your policy requires it

Reset script parameters and custom preferences that hold environment-specific values (URLs, folder IDs, email addresses)

#### Validate and record

**Items:**

Test logins for each tester role, including SSO and 2FA

Run smoke tests on the core flows: sales order to invoice, purchase order to bill, work order to assembly build

Run one call per integration and confirm it hits the sandbox, not production

Expect attachments and documents to arrive as metadata only, not as files, and tell testers who need them

Record the refresh date, source account and who requested it in your change log

Reopen the sandbox to developers and lift the freeze

**Scoring Note:** Critical items protect real customers, payments and integrations from a production copy. Do not hand the sandbox back to testers until every critical item is ticked.

## Content

**Intro:** A NetSuite sandbox refresh replaces the sandbox with a copy of production, which wipes sandbox-only work and brings in live email addresses, payment settings and integration endpoints. This checklist covers what to save first, how to request the refresh, and what to fix before anyone tests.

**Sections:**

#### How to use it

**Body:** Work through the groups in order. The first group is done days before the refresh, while developers can still export their work. The second is the request itself, which is made from the production account by an Administrator. The third group must be finished before the sandbox is reopened, because the copy contains real customer and vendor email addresses and live payment profiles. Tick items in the browser and export the result to PDF or Excel as evidence for your change log. If you refresh on a regular schedule, keep the exported list and reuse it, adding any integration you added since the last cycle.

#### What a refresh does and does not copy

**Body:** The refresh copies production data and configuration into the sandbox and overwrites what was there. Some things do not carry over in a usable form, and Oracle's sandbox FAQ lists them; check the current list for your release. In practice, plan on token-based authentication tokens needing to be issued again, SAML identity provider settings needing to be set up again, users repeating 2FA setup, and attachments and documents arriving as metadata only rather than as files. Integration records should be verified, since integrations that only existed in the sandbox are gone. Anything that only lived in the sandbox, including scripts never deployed to production, is lost unless you exported it first.

#### Worked example

**Body:** A manufacturer refreshes SB1 before a project that changes work order costing. The developer has two user event scripts and a custom record in progress, so she exports them as an account customization project. The integration team notes that the 3PL connector and the EDI middleware use TBA tokens in SB1. After the refresh, the admin sets sandbox email to the logged-in user only, finds three scheduled scripts that would email vendors, unschedules two of them, and sets the payment gateway profile to test. The integration team creates new tokens, updates the hosts to 1234567-sb1, and runs one test call each. The developer redeploys her project and testing starts the next morning.

#### Common mistakes

**Body:** Refreshing without exporting sandbox-only work, which is the most common cause of lost effort. Leaving sandbox email set to send to real recipients, so customers receive copies of test invoices. Forgetting that an integration configured with a production account ID will write to production if nobody changes it. Assuming TBA tokens survive the copy. Refreshing during user acceptance testing, which removes testers' data. Not recording the refresh date, which makes it hard to tell later whether a sandbox object came from production or from a developer.

**Cta:** If you want your team to ask NetSuite in plain English what changed between production and a sandbox, on infrastructure you control, we can set that up.

**Faq:**

#### How do I refresh a NetSuite sandbox?

**Answer:** An Administrator logs in to the production account and requests the refresh from the Sandbox Accounts page under Setup > Company, choosing the sandbox to overwrite. NetSuite queues the copy and sends a notice when it is complete. Export sandbox-only work beforehand and fix email, integrations and payment settings afterwards, as this checklist describes.

#### How long does a sandbox refresh take?

**Answer:** It depends on account size and NetSuite's queue, so plan for the sandbox to be unavailable for at least a day and do not schedule testing until you receive the completion notice. Larger accounts with many transactions and files take longer. Do not promise testers a time based on a previous refresh.

#### Can I sync only some data from production to sandbox?

**Answer:** A sandbox refresh is a full copy, not a selective sync. To move selected configuration, use SuiteCloud Development Framework projects or the Copy to Account feature where available. To move selected data, use CSV import or an integration. Choose this route when a full refresh would destroy too much sandbox work.

#### Why do integrations fail after a sandbox refresh?

**Answer:** Usually because tokens or integration records the integration relied on are not usable after the copy, or because the integration still points at the old sandbox or at production. Issue new tokens, confirm the integration record, update the account ID in the host name, and check the Login Audit Trail for the failure reason.

## Search terms

netsuite sandbox refresh, how to refresh netsuite sandbox, netsuite sandbox refresh steps, netsuite how to do a sandbox refresh, how to update sandbox in netsuite, how to sync netsuite sandbox, netsuite sandbox refresh what is not copied

---
Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json
