# Managing NetSuite sandbox refresh alongside SDF deployments > Source: https://netray.co/erp-help/netsuite-sandbox-refresh-sdf-deployment > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: ERP Help ## Short answer A NetSuite sandbox refresh clones production data and customization state into the sandbox account, which means any sandbox-only changes not captured in an SDF (SuiteCloud Development Framework) project are wiped, while changes that were already deployed to production survive because they come along with the refresh. Plan refreshes around your deployment calendar, and redeploy or validate your SDF project immediately after every refresh. ## Kind advanced ## System netsuite ## Erp Oracle NetSuite ## Module SuiteCloud Development Framework (SDF) ## Query how does NetSuite sandbox refresh affect SDF deployments ## Alternate Queries - netsuite sdf deploy account customization project - suitecloud cli project deploy failed - netsuite sandbox refresh schedule and customizations - netsuite manifest.xml deploy.xml explained ## Applies To NetSuite sandbox accounts, SuiteCloud Development Framework (SDF) projects, SuiteCloud CLI for Node.js ## Steps ### Coordinate sandbox refresh with an SDF workflow **Items:** Check the account's sandbox refresh eligibility and schedule at Setup > Company > Sandbox Refresh Status; refresh frequency is tied to the account's contract (commonly limited to a certain number of refreshes per period, not on-demand daily). Before requesting or accepting a scheduled refresh, confirm the SDF project's current state is captured: run suitecloud project:validate and commit any pending custom object XML changes to source control so nothing sandbox-only is lost. Understand that refresh overwrites the sandbox with a copy of production, including data and the production customization state; anything deployed to sandbox but not yet deployed to production is replaced by whatever exists in production at refresh time. After refresh completes, re-run suitecloud account:setup (or reconfirm the saved authentication ID) since role IDs, internal IDs and some environment-specific references can differ or need re-validation post-refresh. Run suitecloud project:deploy (or project:validate first, then deploy) to reapply the SDF project's custom objects, scripts and File Cabinet content to the freshly refreshed sandbox. Check deploy.xml to confirm it still references the correct set of objects and files; a project that grew since the last refresh needs deploy.xml (or the auto-generated manifest for object-based deploys) kept in sync with everything intended to ship. Re-test integration credentials (TBA tokens, OAuth 2.0 client credentials) issued specifically for the sandbox, since refresh can invalidate previously issued sandbox tokens tied to the old sandbox state. Re-run any post-deploy configuration steps that live outside SDF's scope (for example, feature enablement, certain preferences, or non-SDF-managed saved searches) that a refresh would also have reset to production's state. ## Sections ### What survives a refresh and what does not **Body:** Data, and customizations that are part of production's current state, survive because refresh literally clones production into the sandbox. If a feature, script or custom record was already live in production before the refresh, it comes along automatically. What does not survive is anything that exists only in the sandbox and has not been promoted to production: unreleased script versions being tested, sandbox-only configuration used for QA, or in-progress customizations tracked in an SDF project locally but never deployed to that sandbox account before the refresh replaced it. This is why teams that rely on SDF treat the sandbox as disposable and the SDF project (in source control) as the source of truth; redeploying after a refresh is expected, routine work, not a recovery exercise. ### manifest.xml, deploy.xml and the deploy unit **Body:** An SDF project's manifest.xml declares the project's basic metadata and required features/dependencies, while deploy.xml lists exactly which objects, files and configuration should be included when suitecloud project:deploy runs, using path patterns under Objects/ and FileCabinet/. Keeping deploy.xml accurate matters most right after a refresh: if it excludes a directory or object type that was added since the file was last edited, that content silently will not deploy, and the freshly refreshed sandbox will be missing customizations that developers assume are already there. **Code:** ~/AccountConfiguration/* ~/FileCabinet/SuiteScripts/* ~/Objects/* ### CI/CD around scheduled refreshes **Body:** Teams running SuiteCloud CLI in a CI/CD pipeline (using a saved authentication ID or CI-specific credentials) typically add a manual gate or a scheduled job right after each known sandbox refresh window to immediately validate and redeploy, so developers do not lose a day discovering the sandbox reverted underneath them. It is also worth versioning the SDF project's account-specific overrides (different script deployment IDs, employee/role internal IDs between sandbox and production) carefully, since a refresh can shift what 'the sandbox' contains without changing the SDF project files themselves, which is a common source of deploy-time ID mismatches. ## Pitfalls - Assuming sandbox refresh only touches data and not customizations, then being surprised when unreleased scripts disappear. - Not committing SDF project changes to source control before a scheduled refresh, losing track of what needs to be redeployed. - Forgetting to re-issue or re-test sandbox-specific integration credentials after a refresh invalidates the previous sandbox state. - Letting deploy.xml drift out of sync with the actual Objects/ and FileCabinet/ directories, so a redeploy after refresh silently omits new customizations. - Treating a refresh as available on demand when the account's contract only allows a limited number per period, leading to scheduling conflicts with QA or UAT cycles. ## Ai Angle SyteRay-style grounded review of an SDF project's manifest.xml and deploy.xml can flag, before a redeploy, objects or files that exist on disk but are not referenced by deploy.xml (or vice versa), which is exactly the drift that causes silent gaps right after a sandbox refresh. It can also summarize what changed in a refreshed sandbox compared to the last known SDF deploy state, saving a manual diff. ## Faq ### How often can I refresh a NetSuite sandbox? **Answer:** Refresh frequency depends on the account's contract and sandbox tier; many accounts are limited to a set number of refreshes over a period rather than being able to refresh on demand daily, so check Setup > Company > Sandbox Refresh Status for the account's actual allowance. ### Will a sandbox refresh delete my SuiteCloud CLI saved authentication? **Answer:** The locally saved authentication ID on the developer's machine is unaffected, but tokens or credentials that were specific to the sandbox's prior state (such as TBA tokens issued in that sandbox) can be invalidated, so re-authenticating after a refresh is good practice. ### Does refresh affect production, or only the sandbox being refreshed? **Answer:** Only the sandbox being refreshed is affected; production is the source that gets copied from, and other sandboxes are untouched unless they are also scheduled for refresh separately. ### Should every customization go through SDF instead of being made directly in the sandbox UI? **Answer:** For anything meant to reach production, yes. Direct UI changes in a sandbox that are never captured in an SDF project are exactly what gets lost on the next refresh, whereas an SDF project in source control can always be redeployed regardless of how many times the sandbox is refreshed. ## Search terms netsuite sandbox refresh sdf, suitecloud project deploy, netsuite manifest.xml deploy.xml, netsuite sandbox refresh schedule, suitecloud cli account setup, netsuite sdf ci/cd pipeline, netsuite sandbox refresh lost customizations, suitecloud project validate, netsuite deploy.xml objects filecabinet --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json