Get the current user's sys_id

The gs.getUserID() method returns the sys_id of the currently logged-in user as a string. This is the most direct way to get user identity in server-side scripts, but developers consistently stumble on the async execution gotcha: when Business Rules run asynchronously or in scheduled contexts, the "current user" becomes the system user, not the person who triggered the original transaction. This happens because async operations execute outside the original user session, fundamentally changing the security and audit context of your script.

When to use this

• In synchronous Business Rules when you need the actual user who performed the action
• In Script Includes called from client-side scripts to maintain user context
• When setting ownership, assignment, or audit fields based on who initiated the change
• In Fix Scripts when you want to track which admin ran the script

When NOT to use this

• In async Business Rules where you need the original user — store the user ID in a field during the sync phase instead
• In Scheduled Jobs where user context is meaningless — use a dedicated service account field
• When you need user profile data — use gs.getUser() which returns a GlideUser object with all user properties
• In client scripts — user context doesn't exist server-side from client calls

Key behaviors and gotchas

• Returns a 32-character string sys_id, never null in sync contexts, but can be null in scheduled jobs
• Async Business Rules return the system user ID (usually admin or system), not the original user who triggered the rule
• Web Service calls and integrations execute as the endpoint's configured user, not the API caller
• Domain separation affects visibility — the user ID is always returned, but queries using it may return no results due to domain restrictions
• Impersonation changes the returned user ID to the impersonated user, not the admin doing the impersonating
• Mid-server script execution returns the mid-server's configured user, not the original requestor