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 — previous doesn'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_audit queries or Scheduled Jobs instead
  • Don't use manual previous comparison without null checking — it will fire incorrectly on insert operations

Key behaviors and gotchas

  • The changes() method returns false on 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 using previous approach — 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 returns true when 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.

Free Newsletter

Enjoying this? Get one deep-dive per week.

Join 1,000+ ServiceNow pros — scripts, GlideRecord patterns, Flow Designer techniques, and career moves. Free.

No spam · Unsubscribe anytime