Query incidents by caller

The platform stores user references as sys_id values, not user names or employee numbers. Querying by caller_id requires the user's 32-character GUID — never query incidents by joining to sys_user.user_name or sys_user.employee_number as that forces expensive table scans. Most developers initially try to query by user name because it's human-readable, but this pattern performs terribly and breaks when users change their login names.

When to use this pattern

• When processing incidents for the current logged-in user in Business Rules or Script Includes
• When you have a user reference field and need their related incidents (assignment rules, escalations)
• When building user dashboards or notification logic that operates on bounded result sets
• When you need to read multiple field values per incident (priority, state, assignment group)

When NOT to use this pattern

• Don't use in Client Scripts — use GlideAjax to call a Script Include instead
• Don't use when you only need a count — use GlideAggregate with addAggregate('COUNT')
• Don't loop this inside another GlideRecord loop — you'll create N+1 query performance problems
• Don't use for reporting or bulk data analysis — use scheduled jobs with setLimit() and pagination

Key behaviors and gotchas

• The caller_id field is indexed, making queries by user sys_id fast even on large incident tables
• State 7 is 'Closed' — always exclude closed incidents unless specifically needed to avoid processing stale data
• ACLs still apply — users will only see incidents they have read access to, even when queried server-side
• Domain separation affects results — incidents from other domains won't appear unless you're in the global domain
• Priority values are integers: 1 (Critical), 2 (High), 3 (Moderate), 4 (Low), 5 (Planning) — don't compare to strings
• Use getValue() for sys_ids and exact comparisons, getDisplayValue() for logging human-readable values