Fix Script vs Scheduled Job in ServiceNow — Which One Should You Use?

ServiceNow Scheduled Job vs Fix Script — When to Use What

While working in ServiceNow, there are common scenarios where you need to update records in bulk or run background operations. Two powerful approaches are Scheduled Jobs and Fix Scripts — but knowing when to use each one is essential for ServiceNow developers and administrators.

This guide covers the key differences with real code examples and interview questions.

What is a Scheduled Job in ServiceNow?

A Scheduled Job is used for automated, recurring execution of scripts on a defined schedule. It runs without manual intervention.

When to use Scheduled Job:

• Daily cleanup of old or resolved records
• Sending scheduled notifications or reports
• Periodic data synchronization with external systems
• Auto-closing incidents after a set number of days
• Running weekly compliance reports

Benefits:

• ✔ Runs automatically based on a schedule (daily, weekly, hourly, monthly)
• ✔ No manual trigger needed
• ✔ Ideal for ongoing, repeating background processes
• ✔ Reduces manual work and human error
• ✔ Can be monitored in System Scheduler

What is a Fix Script in ServiceNow?

A Fix Script is used for one-time data corrections or updates, typically after a deployment or to fix data issues. It is run manually by an administrator.

When to use Fix Script:

• Fixing incorrect or missing data in records
• Updating records after a new deployment or configuration change
• Backfilling field values in bulk
• One-time data migration or consolidation
• Correcting data after a system incident

Benefits:

• ✔ Runs manually — triggered by an admin when needed
• ✔ Full control over when and how the script executes
• ✔ Typically used once and not repeated
• ✔ Safer for audit-sensitive changes
• ✔ Easier to troubleshoot if issues occur

Scheduled Job vs Fix Script — Key Differences

Feature	Scheduled Job	Fix Script
Execution Type	Automatic	Manual
Frequency	Recurring (Daily/Weekly/Monthly)	One-time
Execution Trigger	Schedule (Cron)	Admin runs manually
Best For	Ongoing processes	Data corrections
Manual Intervention	Not needed	Required

Fix Script Code Examples

Here are practical examples of using Fix Scripts for one-time data updates in ServiceNow.

Example 1: Update Active Incidents

var gr = new GlideRecord('incident');
gr.addQuery('active', true);
gr.setLimit(100);  // Process only 100 records
gr.query();

while (gr.next()) {
    gr.setValue('priority', '2');
    gr.update();
}

gs.log('Updated ' + gr.getRowCount() + ' active incidents');

What this does:

• Queries all active incidents
• Limits the update to 100 records (for testing)
• Changes priority to 2 (Medium)
• Updates each record

When to use:

• Testing before a large update
• Safety: limits records to prevent accidental mass changes
• Good for data validation before production run

Example 2: Update Records Based on Condition

var gr = new GlideRecord('incident');
gr.addQuery('priority', '1');  // Query high-priority incidents
gr.query();

while (gr.next()) {
    gr.setValue('state', '2');  // Change state to "In Progress"
    gr.update();
}

gs.log('Updated incident states to In Progress');

What this does:

• Finds all incidents with priority = 1 (High)
• Changes their state to 2 (In Progress)
• Updates each record in the database

When to use:

• Post-deployment: if a new workflow requires priority 1 incidents to be "In Progress"
• Bulk state transitions
• Data corrections after system changes

Example 3: Backfill Missing Values

var gr = new GlideRecord('incident');
gr.addQuery('short_description', '');  // Find empty short descriptions
gr.query();

var count = 0;
while (gr.next()) {
    gr.setValue('short_description', 'Auto-populated from description');
    gr.update();
    count++;
}

gs.log('Backfilled ' + count + ' incidents with missing short_description');

What this does:

• Finds incidents with empty short_description field
• Fills it with a default value
• Tracks how many records were updated

When to use:

• Data cleanup after migration
• Filling required fields that were previously empty
• Preparation before deploying new field requirements

Pro Tips for Fix Scripts

1. Always Use setLimit() While Testing

var gr = new GlideRecord('incident');
gr.addQuery('active', true);
gr.setLimit(10);  // Test with 10 records first
gr.query();

Why: Prevents accidental updates of thousands of records. Test with a small number first.

2. Add Logging to Track Changes

var count = 0;
while (gr.next()) {
    gr.setValue('priority', '2');
    gr.update();
    count++;
}
gs.log('Successfully updated ' + count + ' records');

Why: Helps verify the script ran correctly and shows how many records were affected.

3. Always Test in Dev First

Before running a Fix Script in production:

1. Run it in your dev instance
2. Verify the results
3. Check the change logs
4. Then run in test/staging
5. Finally, run in production

Scheduled Job Code Example

Here's a simple Scheduled Job for comparison:

// Scheduled Job: Daily cleanup of resolved incidents
var gr = new GlideRecord('incident');
gr.addQuery('state', '7');  // Resolved state
gr.addQuery('resolved_on', '<', new GlideDateTime().addDays(-30).getValue());  // Older than 30 days
gr.query();

var count = 0;
while (gr.next()) {
    gr.deleteRecord();
    count++;
}

gs.log('Scheduled Job: Deleted ' + count + ' resolved incidents older than 30 days');

Why this is a Scheduled Job:

• Runs automatically every day (set in System Scheduler)
• Cleans up old data regularly
• No manual trigger needed
• Keeps the database clean and performant

When to Use Fix Scripts vs Scheduled Jobs

Use Scheduled Job when:

• You need the same task to run multiple times
• The task should run at specific times (daily, weekly)
• You want to automate a recurring business process
• Examples: Cleanup jobs, periodic syncs, notification batches

Use Fix Script when:

• You need to fix data after a deployment
• It's a one-time operation that won't repeat
• You need full control over execution
• Examples: Backfill missing values, correct bad data, bulk updates

Interview Questions

Q. What is the difference between a Scheduled Job and a Fix Script in ServiceNow?

A. A Scheduled Job runs automatically on a set schedule and is used for recurring, background tasks like daily cleanups or periodic notifications. A Fix Script is run manually and is used for one-time data corrections, typically after a deployment or to fix data issues. Scheduled Jobs are automated and recurring, while Fix Scripts are controlled and executed once.

Q. When would you use a Scheduled Job instead of a Fix Script?

A. Use a Scheduled Job when you have a task that needs to run repeatedly on a schedule — such as daily record cleanup, weekly reports, or periodic data updates. If the task is a one-time fix (like correcting data after a deployment), use a Fix Script instead.

Q. What precaution should you take when running a Fix Script?

A. Always test the Fix Script in a lower environment (dev/test) with a small dataset first using setLimit(). Verify the results before running it in production. Add logging to track changes and always create a backup of your data before bulk updates.

Q. Can you give an example of when you would use a Fix Script?

A. A Fix Script would be used after a deployment if you realized a new field validation requires existing records to be updated. For example, if a new field "assignment_group" is now mandatory, you could run a Fix Script to backfill all incidents with a default assignment group before enforcing the validation.

Best Practices

• ✔ Use Scheduled Jobs for ongoing automated processes
• ✔ Use Fix Scripts for controlled, one-time data fixes
• ✔ Always test Fix Scripts in dev/test environment first
• ✔ Use setLimit() when testing to avoid performance issues
• ✔ Add logging (gs.log()) to track script execution
• ✔ Never run bulk update scripts directly in production without testing
• ✔ Keep audit trail by documenting why and when Fix Scripts were run
• ✔ Use gr.getRowCount() to verify how many records were affected

Key Takeaways

• ✔ Scheduled Job = Automated + Recurring
• ✔ Fix Script = Manual + One-time
• ✔ Use Scheduled Jobs for background processes
• ✔ Use Fix Scripts for controlled data corrections
• ✔ Always test with setLimit() before bulk updates
• ✔ Add logging to track changes
• ✔ Never run directly in production without testing