ServiceNow provides three different methods to get current user information, and developers consistently choose the wrong one. gs.getUserName() returns the login name, gs.getUserDisplayName() returns the formatted full name, and gs.getUser().getEmail() gets the email address. The critical mistake is trying to use gs.getUserEmail() (which doesn't exist) or querying the sys_user table directly, which creates unnecessary database calls and ignores ServiceNow's session caching.
When to use this pattern
- In Business Rules when you need to stamp user information onto records
- In Script Includes that need current user context for authorization logic
- In Scheduled Jobs that run as a specific user and need to reference that user's details
- In email notifications or logging where you need human-readable user identification
When NOT to use this pattern
- Don't use in client scripts β these methods don't exist client-side, use
g_user.userNameandg_user.displayNameinstead - Don't use in system-context Scheduled Jobs β they return
'system'or null, usegs.setProperty()to pass user context instead - Don't query
sys_usertable directly when you just need basic user info β thesegsmethods use cached session data - Don't use when you need extended user properties like department or location β query
sys_userdirectly for those fields
Key behaviors and gotchas
gs.getUserName()returns theuser_namefield value (login name), not the display name β use for database references and logginggs.getUserDisplayName()returns formattedfirst_name + last_nameβ use for user-facing messages and displaysgs.getUser().getEmail()can return empty string if user has no email β always null-check before using- All three methods return
'system'or null in elevated/system contexts like some Scheduled Jobs and import operations - These methods respect impersonation β if admin is impersonating another user, they return the impersonated user's details
- Results are cached per session β no performance penalty for multiple calls within the same transaction
gs.getUser().getEmail() fails silently in some execution contexts and returns an empty string instead of throwing an error. Always check for empty results before using the email value in notifications or database operations.
Enjoying this? Get one deep-dive per week.
Join 1,000+ ServiceNow pros β scripts, GlideRecord patterns, Flow Designer techniques, and career moves. Free.