The Sandbox That Drifted
A 120-user NetSuite account has Production plus one Sandbox. During a quarterly refresh, the administrator notices that two custom transaction body fields on Sales Order were created directly in Production three weeks ago and never documented. A SuiteScript 2.1 User Event script referencing those fields is deployed in Production but not in Sandbox. Meanwhile, an approval workflow that was retired in Production is still active in Sandbox and has been emailing test users. The next refresh is scheduled in 48 hours, and the team wants to validate the new script before the month-end close in 10 days.
1. Should the team proceed with the scheduled sandbox refresh, and what must happen first?
Read the worked answer
No - not until the Production-only artifacts are captured. A refresh overwrites Sandbox with a copy of Production, so anything only in Sandbox (including the retired workflow's residue) is destroyed, but anything only in Production comes along automatically.
Sequence:
- Export/record the two custom fields and the script deployment from Production (SDF or manual capture) so they are documented before the refresh.
- Confirm the retired workflow is already inactive in Production - after refresh it will inherit Production's inactive state, resolving the email symptom.
- Run the refresh, then validate the script in Sandbox against a copy of production-like data.
- Only promote to Production after validation, leaving margin before month-end close.
Key judgement: the refresh solves the workflow drift but does not solve the documentation gap - and it wipes any Sandbox-only work, so anything to keep must be extracted first.
2. A developer proposes building the script fix directly in Production to save time. Evaluate this against the refresh timeline.
Read the worked answer
Reject it. Building in Production during a 48-hour refresh window means:
- The change is untested against real data and lands during a period when the team is already destabilized.
- Any Production change made now will be copied into Sandbox at refresh, potentially overwriting or conflicting with the Sandbox validation work.
- Month-end close in 10 days leaves no rollback window if the script misbehaves.
Correct path: capture the existing Production artifacts, refresh, develop and test in Sandbox, then deploy via a controlled bundle. The 48-hour window is a reason to freeze Production, not accelerate changes into it.