Query incidents created in the last 7 days

Date queries in ServiceNow are deceptively complex because the platform stores all dates in UTC but developers often think in local time. The pattern above uses GlideDateTime.addDaysUTC(-7) specifically to avoid timezone conversion issues that plague JavaScript Date objects. When you use raw JavaScript dates in queries, ServiceNow silently converts them using the session timezone, leading to off-by-hours bugs that only surface when users in different timezones run your code.

When to use this pattern

• When you need to query records based on creation or modification dates within a specific timeframe
• In Business Rules where you're processing records server-side and need reliable timezone handling
• For Scheduled Jobs that need consistent date boundaries regardless of when they run
• When building reports or metrics that require precise date range filtering

When NOT to use this pattern

• In client scripts — use GlideAjax to call a Script Include that performs the query server-side
• When you only need a count — use GlideAggregate with addAggregate('COUNT') instead
• For queries that could return thousands of records — add setLimit() or use chunked processing
• Inside loops over other GlideRecord results — you'll create N+1 query problems

Key behaviors and gotchas

• The sys_created_on field is indexed on most tables, making these queries perform well even on large datasets
• State values are integers: New=1, In Progress=2, Resolved=6, Closed=7 — never query by state labels
• Priority values are also integers: Critical=1, High=2, Moderate=3, Low=4, Planning=5
• Use getValue() for references and choice fields to get the actual stored value, not the display value
• ACLs still apply to GlideRecord queries — if the executing user can't read incidents, the query returns no results
• Domain separation affects results — queries only return records in domains the session user can access