Fix scripts and data migration in Development

Fix scripts and data migration

Run one off data changes safely, with dry runs, batching and a record of what happened.

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.

Practice challenge

+0 XPStreak ×0

Question 1 of 2

What makes a fix script safer than a background script?

Frequently asked questions

Fix script or background script?

Background scripts are for ad hoc investigation. Fix scripts are recorded, reviewable and can travel in an update set, so use them for anything that matters.

How do we undo a bad run?

You restore from backup or write a compensating script. That is exactly why dry runs and batching matter.