Fix scripts and data migration
Quick answer
Run one off data changes safely, with dry runs, batching and a record of what happened.
Key takeaways
- Fix scripts ship data changes with configuration
- Dry run and log counts before writing anything
- Batch large changes, do not run unbounded loops
- setWorkflow(false) is a deliberate, documented choice
What a fix script is
A fix script is server side code stored as a record, runnable on demand and capable of being included in an update set so it runs once on the target instance after commit. That makes it the supported way to ship a data change alongside configuration.
Running safely
Data changes are hard to undo.
var DRY_RUN = true;
var count = 0;
var gr = new GlideRecord('incident');
gr.addEncodedQuery('active=true^category=inquiry');
gr.setLimit(500);
gr.query();
while (gr.next()) {
count++;
if (!DRY_RUN) { gr.category = 'request'; gr.setWorkflow(false); gr.update(); }
}
gs.info('Fix script processed ' + count + ' records, dry run ' + DRY_RUN);Rules of thumb
Always dry run first and log the count. Batch large updates with setLimit and repeat runs rather than one unbounded loop. Use setWorkflow(false) when you do not want business rules and notifications to fire, and state clearly in the script description why that decision was made.
Want to learn this properly?
Our live, instructor-led ServiceNow Training covers this hands-on, with real projects and a certification path.
Check your understanding
What makes a fix script safer than a background script?
- A. It runs faster
- B. It is a record that can be reviewed and shipped
- C. It bypasses ACLs
- D. It cannot fail
Show answer
B. It is a record that can be reviewed and shipped
Being a stored, reviewable artefact is the point.
What should every data script log?
- A. The user agent
- B. Processed counts and whether it was a dry run
- C. The table schema
- D. The instance name
Show answer
B. Processed counts and whether it was a dry run
Counts make the outcome verifiable afterwards.