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.userName and g_user.displayName instead
  • Don't use in system-context Scheduled Jobs β€” they return 'system' or null, use gs.setProperty() to pass user context instead
  • Don't query sys_user table directly when you just need basic user info β€” these gs methods use cached session data
  • Don't use when you need extended user properties like department or location β€” query sys_user directly for those fields

Key behaviors and gotchas

  • gs.getUserName() returns the user_name field value (login name), not the display name β€” use for database references and logging
  • gs.getUserDisplayName() returns formatted first_name + last_name β€” use for user-facing messages and displays
  • gs.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.

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