Dot-walking lets you access fields on referenced records without writing separate GlideRecord queries, but it's not magic — each referenced field triggers a lazy-loaded database query the first time you access it. The platform caches the referenced record after the first field access, so current.assignment_group.manager.email followed by current.assignment_group.manager.phone only hits the database once. Most developers don't realize that dot-walking in loops creates N+1 query situations that will destroy performance at scale.
When to use this
- Processing single records in Business Rules where you need 1-2 fields from referenced records
- Script Includes or Fix Scripts handling bounded result sets (under 100 records)
- When you need fields from multiple reference levels like
incident.assignment_group.manager.department - Scheduled Jobs processing records where clean, readable code matters more than maximum performance
When NOT to use this
- Inside loops over
GlideRecordresult sets — usegetRefRecord()or join queries instead - When you need multiple fields from the same referenced record —
getRefRecord()is more explicit and performs identically - Processing more than 200 records in a single execution — you'll hit query limits
- Client-side scripts — references don't dot-walk in
GlideForm, useg_form.getReference()or GlideAjax
Key behaviors and gotchas
- Each dot-walk level triggers a separate query on first access —
gr.assignment_group.manager.emailexecutes two queries total - Always check
.nil()before accessing fields on referenced records — empty references return empty strings, not null - Referenced record queries respect ACLs — you might not get the field value even if the reference exists
- Dot-walking to inactive or deleted records returns empty values without errors — check record state if it matters
- Domain separation applies to each reference level — cross-domain references may return empty even with valid sys_ids
- In loops, store dot-walked values in variables — don't call
current.assignment_group.namemultiple times
Dot-walking inside while loops creates N+1 queries that scale terribly. A 500-record query with dot-walking becomes 1,500+ database calls and will time out in production. Use JOIN queries or getRefRecord() with caching instead.
Enjoying this? Get one deep-dive per week.
Join 1,000+ ServiceNow pros — scripts, GlideRecord patterns, Flow Designer techniques, and career moves. Free.