Session

What It Is

A ServiceNow session represents an authenticated user's active connection to an instance, maintaining state between HTTP requests and tracking user context throughout their interaction with the platform. Unlike generic web sessions that simply store arbitrary data, ServiceNow sessions are tightly integrated with the platform's security model, carrying user roles, domain access, language preferences, and UI personalization settings. The session acts as the authoritative source of "who is this user and what can they do" for every server-side operation, from database queries to workflow executions.

Architecturally, sessions sit at the application layer, bridging the stateless HTTP protocol with ServiceNow's stateful security and personalization requirements. Every server-side script execution—whether in Business Rules, Script Includes, or scheduled jobs—occurs within a session context that determines database access permissions, field visibility, and workflow execution rights. The session object provides the runtime environment that makes role-based access control actually work, ensuring that a user with itil role cannot access records they shouldn't see, even if a developer writes a GlideRecord query that doesn't explicitly filter by permissions.

From a business operations perspective, sessions solve the fundamental problem of secure, personalized access to enterprise service management systems. In ITSM workflows, sessions ensure that when a service desk agent updates an incident, the system knows exactly which agent made the change, what data they're authorized to see, and which approval workflows should trigger based on their role. For ITOM operations, sessions enable technicians to access only the infrastructure data relevant to their responsibilities while maintaining audit trails. In ITAM scenarios, sessions prevent unauthorized users from accessing sensitive asset information while ensuring procurement managers can see cost data across their domains.

ServiceNow designed sessions this way because enterprise applications require persistent user context across complex, multi-step business processes that span multiple HTTP requests. Traditional web applications might authenticate once and trust the client, but ServiceNow's approach assumes every server-side operation needs fresh authorization checks against current user permissions. This design choice creates some complexity—sessions can timeout mid-workflow, causing user frustration—but it provides the security model that enterprise IT departments demand. Alternative approaches like JWT tokens or client-side session management couldn't provide the same level of server-side security integration without fundamental changes to how ACLs and business rules operate.

End users interact with sessions transparently through login and logout, experiencing them primarily as timeout interruptions during long form-filling sessions. Administrators configure session policies, set timeout values, and troubleshoot authentication issues, often needing to understand how session configuration affects user experience and system performance. Developers work directly with session data through gs.getSession() to access user information, modify session variables, and implement custom security logic. Process owners care about sessions when designing workflows that might exceed timeout periods or when audit requirements demand detailed session tracking for compliance purposes.

Without sessions, ServiceNow would collapse into a security nightmare where every script would need explicit authentication and authorization logic, where user preferences couldn't persist across page loads, and where audit trails would lose the crucial "who did what" context that makes enterprise service management possible. Role-based access control would become a client-side suggestion rather than a server-side enforcement mechanism. Multi-step processes like change approvals or incident escalations would break because the system couldn't maintain user context between stages. The entire foundation of personalized, secure enterprise application functionality depends on sessions maintaining that critical bridge between stateless web protocols and stateful business process requirements.

Where It Fits in the Platform

Sessions operate at the intersection of ServiceNow's security layer and application layer, serving as the runtime context for all user-initiated operations. They integrate deeply with the Access Control List (ACL) system, Domain Separation architecture, and the GlideSystem framework, making them foundational to how the platform enforces security and delivers personalized experiences. Every database query through GlideRecord inherits session-based permissions, every Business Rule execution runs within session context, and every UI rendering considers session-stored preferences.

The session management system connects horizontally across ServiceNow's entire technology stack, from the web server handling HTTP requests down to database access patterns and workflow engines. Sessions influence everything from which fields appear on forms to which records show up in reports, making them one of the most pervasive concepts in the platform even though they often remain invisible to casual users. Understanding sessions means understanding how ServiceNow bridges stateless web technology with stateful enterprise business processes.

Key Relationships:

• GlideSystem: The gs.getSession() method provides server-side access to session data, user information, and session manipulation capabilities. Sessions are accessed exclusively through GlideSystem APIs in server-side scripts.
• Access Control Lists (ACLs): Sessions provide the user context that ACLs evaluate to determine field and record access permissions. Every ACL script execution receives session information to make authorization decisions.
• Domain Separation: Sessions maintain current domain context, ensuring users only access data within their authorized domains. Domain switching requires session updates to maintain proper security boundaries.
• User Preferences: Sessions store and retrieve personalization settings like language, timezone, and UI configuration. These preferences persist across requests and influence how the platform renders pages and formats data.
• Business Rules: All Business Rule executions occur within session context, inheriting user permissions and access to session variables. Business Rules can read and modify session data to implement custom security or workflow logic.
• Authentication: Sessions are created after successful authentication and destroyed during logout or timeout. The authentication system manages session lifecycle and handles session security policies like idle timeouts and concurrent session limits.

How You Encounter This in Practice

Debugging User Permission Issues

A ServiceNow developer receives a ticket that users in the London office can't see certain incident records that should be visible based on their roles, but the same roles work fine for users in other locations. The developer discovers that domain separation is configured, and these users' sessions are locked to the wrong domain context. By examining gs.getSession().getCurrentDomainID() in server-side scripts and comparing it to the domain values on the incident records, they identify that user authentication is assigning the wrong default domain. Understanding sessions reveals that the problem isn't with ACLs or role assignments, but with how session domain context gets established during login.

Without understanding sessions, a developer would waste time checking role assignments, ACL configurations, and record-level security, never realizing that the session itself carries domain context that overrides everything else. They might even create custom ACLs or modify role permissions, introducing security vulnerabilities while failing to address the root cause of incorrect session domain assignment.

Implementing Custom Workflow Security

A senior administrator needs to implement a change management process where certain high-risk changes can only be approved by users who are physically logged in from specific network locations during business hours. Standard role-based security isn't sufficient because the same user might need different permissions based on their current session context. The administrator discovers they can access gs.getSession().getClientIP() and gs.getSession().getSessionToken() in Business Rules to implement location-aware and time-based access controls. By storing custom flags in session variables through gs.getSession().putClientData(), they create dynamic security that adapts to current session context rather than static role assignments.

Understanding sessions enables sophisticated security implementations that consider real-time context, not just static permissions. Someone without this knowledge would try to solve the problem with increasingly complex role hierarchies or try to hack together client-side solutions that could be easily circumvented, never realizing that session data provides secure, server-side access to the contextual information they need.

Troubleshooting Timeout-Related Process Failures

A process owner reports that users frequently lose their work when filling out complex change requests that take longer than 30 minutes to complete, and the standard solution of extending session timeouts creates security concerns from the IT security team. A ServiceNow administrator realizes that the issue isn't just about timeout duration, but about how session expiration interacts with form submission and draft saving. By examining session timeout behavior and implementing custom session extension logic using gs.getSession().isLoggedIn() checks in client-callable Script Includes, they create a solution that extends sessions only for active form editing while maintaining standard timeout policies for idle users. They discover that sessions can be programmatically extended based on user activity patterns rather than applying blanket timeout policies.

Without understanding sessions, administrators would either compromise security by extending timeouts globally or frustrate users by forcing them to repeatedly log back in. They might try client-side solutions that don't actually extend server-side session validity, or implement complex form auto-save mechanisms that don't address the underlying session expiration problem, missing the opportunity to create intelligent, activity-based session management.

What People Get Wrong

ServiceNow sessions are fundamentally different from typical web application sessions because they're deeply integrated with the platform's security and business logic infrastructure. While generic web sessions might store user preferences and temporary data, ServiceNow sessions actively participate in every database query, ACL evaluation, and business process execution. They don't just remember who you are—they actively enforce what you can do, see, and modify in real-time. This misconception leads developers to treat sessions as simple data storage, missing the fact that session manipulation can affect security boundaries and business rule execution.

This misunderstanding exists because most developers have experience with traditional web frameworks where sessions are passive data containers. In ServiceNow, sessions are active participants in platform security, carrying role context, domain boundaries, and user impersonation state that affects every server-side operation. When developers treat sessions like simple storage, they miss opportunities to implement sophisticated security controls and may inadvertently create security vulnerabilities by not understanding how session data influences access control decisions.

In production, this misconception manifests as developers who store sensitive business data in session variables without understanding that session data persists across requests and can be accessed by any server-side script running in that session context. They might also miss the fact that session variables can be used to pass context between Business Rules, workflow activities, and UI Actions in ways that static parameters cannot. More critically, they fail to leverage session-based security controls, instead building custom authorization logic that duplicates functionality already available through session context, creating maintenance overhead and potential security gaps.

Session timeouts serve as a critical security control that limits the window of exposure when users leave workstations unattended or when session tokens are compromised. Extending timeout periods to avoid user complaints creates significant security risks, particularly in environments where users access ServiceNow from shared computers, public networks, or mobile devices. The timeout mechanism isn't just about user convenience—it's about limiting the blast radius of potential security breaches and ensuring that privileged access doesn't persist indefinitely without active user presence.

This misconception arises because administrators see session timeouts primarily as a user experience problem rather than understanding their role in defense-in-depth security strategies. Users complain about losing work due to timeouts, and the visible solution seems to be extending timeout periods rather than implementing proper session management and activity detection. Administrators who don't understand the security implications focus on eliminating user friction without considering that session tokens in memory, browser caches, or network logs could be exploited by malicious actors hours or days after the original user walked away.

In production environments, overly long session timeouts create compliance violations in regulated industries and provide attack vectors for malicious actors who gain access to unattended workstations or compromise session tokens. Extended sessions increase the risk of privilege escalation attacks where low-privilege users gain access to high-privilege sessions, and they complicate audit trails because actions might occur hours after the legitimate user stopped actively using the system. The proper solution involves implementing intelligent session extension based on user activity patterns, using client-side draft saving for long forms, and educating users about security implications rather than simply extending timeout periods beyond reasonable security boundaries.

Admin vs Developer Perspective

For Admins

Admins control session behavior through the System Properties > Session section, where they set timeout values, maximum concurrent sessions per user, and session cleanup intervals. They monitor active sessions via System Diagnostics > Sessions to identify users with stuck sessions or potential security issues. When performance problems arise, admins often need to kill orphaned sessions that are consuming memory or database connections. The key decision is balancing user convenience (longer timeouts) against security and resource consumption - most production instances run 15-30 minute timeouts rather than the default.

For Developers

Developers use gs.getSession() to store and retrieve session-scoped data that needs to persist across page loads but shouldn't be permanent. Common patterns include storing user preferences, wizard state, or temporary flags that control UI behavior within a single session. Session data automatically cleans up when the session expires, making it ideal for temporary state that would otherwise clutter tables or user records. The critical scripting consideration is that session data only exists server-side - you can't access it directly from client scripts without an AJAX call or form submission.

How It Connects to Other Concepts

• User Authentication — Sessions are created after successful authentication and destroyed when users log out or timeout occurs. SSO integrations, MFA challenges, and login policies all affect when and how sessions are established, and session hijacking is prevented through the session token validation that happens on every request.
• GlideSystem (gs) — The primary server-side API for session interaction, where gs.getSession() returns the session object and gs.getSessionID() provides the unique session identifier. Business Rules, Script Includes, and UI Actions all use these GlideSystem methods to access session data and determine session state.
• Database Connections — Each active session can hold database connections from the connection pool, and orphaned sessions are a common cause of connection pool exhaustion. When sessions timeout or are killed, their associated database connections are released back to the pool, which is why session cleanup directly impacts database performance.
• Load Balancing — In clustered environments, sessions are typically sticky to specific nodes, meaning a user's session data and state remain tied to the node where they first authenticated. If that node goes down, the user must re-authenticate and start a new session on a different node, losing any session-stored data.
• Security Roles — Role changes don't automatically update active sessions, so users may retain elevated permissions until their session expires and they re-authenticate. This creates a security window where disabled users or revoked roles remain effective until session timeout, which is why critical security changes often require forced session invalidation.
• Client-side State — Browser cookies store the session ID that links client requests to server-side session data, and session storage/local storage in the browser works independently from ServiceNow sessions. When a ServiceNow session expires, client-side data persists until manually cleared, which can cause confusing user experiences where forms appear to remember data but server requests fail.

Junior vs Senior Knowledge Gap

Junior developers treat sessions as a simple timeout mechanism and often make the mistake of storing large objects or complex data structures in session variables without considering memory implications. They typically don't understand that session data lives in server memory across multiple requests, so storing GlideRecord objects or large arrays can cause memory leaks. A common anti-pattern is using session storage as a substitute for proper database design - storing shopping cart contents or multi-step form data that should really be persisted to temporary tables. Juniors also frequently forget that session data is user-specific and node-specific, leading to bugs where they expect shared state across users or assume session data will survive server restarts.

The senior mental model shift happens when you realize sessions are primarily a security and resource management mechanism, not a convenience feature. Experienced developers understand that session timeout is a security control that balances usability against the risk of abandoned sessions being hijacked. They know that session stickiness in clustered environments creates both performance benefits and failover complications. Seniors design around session limitations rather than fighting them - they architect solutions that gracefully handle session expiration, use session storage sparingly for truly temporary state, and implement proper cleanup patterns.

What never appears in official documentation is how session cleanup affects performance during peak usage periods, and how session configuration impacts database connection pool health. Senior architects know to monitor session metrics alongside database performance because runaway session creation often indicates authentication loops or bot traffic. They understand that aggressive session timeouts can actually hurt performance in high-concurrency environments by forcing more frequent authentication cycles, and that session data serialization can become a bottleneck if not carefully managed.

Experienced architects ask questions like: How does this session timeout policy affect our SSO token refresh cycle? What happens to in-progress workflows when sessions expire? How do we handle session failover in our disaster recovery scenario? They consider session management as part of the broader user experience and security architecture, not just a technical configuration setting. They also know to correlate session patterns with business processes - understanding that batch job schedules, shift changes, and business cycles all create predictable session load patterns that need accommodation.

Quick Reference

• Session timeout resets on every user action, not just page loads - AJAX calls, form submissions, and even some background JavaScript requests extend the session
• The sys_user_session table stores active session records, but querying it directly in production can cause performance issues due to high turnover
• Maximum concurrent sessions per user defaults to 3, but this limit doesn't include mobile app sessions or web service authentication sessions
• Session data stored via putClientData() has a 4KB size limit per key and 64KB total per session across all keys
• Service account and system user sessions never timeout automatically - they must be explicitly terminated or will persist until server restart
• Session cleanup runs every 10 minutes by default but can lag during high load, causing expired sessions to remain active longer than expected
• Cross-frame scripting and embedded iframes create separate session contexts that can have different timeout behaviors than the parent window
• The session warning popup appears at 85% of the timeout period, but this timing can't be customized without modifying core system UI scripts
• Impersonation creates a nested session structure where the impersonator's session remains active alongside the impersonated user's session context
• REST API calls using session-based authentication inherit the same timeout as web UI sessions, unlike OAuth tokens which have independent expiration