The changes() method is cleaner than manual previous comparison because it handles null checks automatically and reads like natural language. Most developers make the mistake of comparing previous.field != current.field without checking if previous exists, causing their logic to fire on insert operations when they only want updates. This creates phantom "changes" that never actually happened.
When to use this
- When you need to trigger notifications or workflows only on specific state transitions
- When you need to audit field changes without flooding logs with unchanged values
- When expensive operations should only run when relevant data actually changes
- When you need to calculate duration or metrics based on field transitions
When NOT to use this
- Don't use
changes()in before Business Rules on insert operations —previousdoesn't exist and will cause script errors - Don't use this in client-side scripts — use
g_form.getOldValue()in onChange client scripts instead - Don't use this when you need to detect changes across multiple records — use
sys_auditqueries or Scheduled Jobs instead - Don't use manual
previouscomparison without null checking — it will fire incorrectly on insert operations
Key behaviors and gotchas
- The
changes()method returnsfalseon insert operations because there's no previous value to compare against - State field comparisons use integers (6 for Resolved, 7 for Closed) not display values — never compare against strings like "Resolved"
- Reference fields require
.toString()for proper comparison when usingpreviousapproach —changes()handles this automatically - Always check
!gs.nil(previous.field)when using manual comparison to avoid false positives on record creation - Business Rules with change detection fire after database commit — the change has already been saved when your logic runs
- Journal field changes are detected properly, but
work_notes.changes()only returnstruewhen new entries are added, not when existing entries are modified
The changes() method will return false positives when comparing fields that contain empty strings vs null values. Always test your change detection with both empty and null previous values to ensure it behaves correctly in production.
Enjoying this? Get one deep-dive per week.
Join 1,000+ ServiceNow pros — scripts, GlideRecord patterns, Flow Designer techniques, and career moves. Free.