Session Timeout
Session Timeout is the inactivity period after which Salesforce ends a user's session and requires re-authentication.
Definition
Session Timeout is the inactivity period after which Salesforce ends a user's session and requires re-authentication. The platform tracks user activity (page interactions, API calls) and resets the timer on each interaction. When the timer elapses without activity, the session is invalidated and any subsequent API call or page load returns a 401 Unauthorized error or redirects the browser to the login page.
Session Timeout is one of two timers Salesforce applies to every session. The inactivity timeout (Timeout Value in Session Settings) is what most admins mean by "session timeout"; it runs from the last user activity. The absolute timeout (Maximum Session Length) runs from session creation regardless of activity. Either timer expiring terminates the session. The inactivity timeout is configurable from 15 minutes to 24 hours; the absolute timeout from 1 hour to 24 hours. Profile-level overrides can tighten either timer for sensitive user populations.
How Salesforce session timeouts work and what to set them to
Inactivity timeout vs absolute timeout: two independent timers
Every Salesforce session has two timers running in parallel. The inactivity timeout resets every time the user interacts with the platform: a page load, a navigation click, an API call, a save. When the timer reaches its configured limit (default 2 hours) without an interaction, the session expires. The absolute timeout starts when the session is issued and runs to its configured limit (default 12 hours) regardless of activity. The session ends when either timer expires, whichever comes first. The interaction between the two means a heavily-active user might stay logged in for the full absolute timeout, while an idle user gets kicked out at the inactivity timeout.
Where session timeout is configured
Org-wide session timeout settings live in Setup, Security, Session Settings. The Timeout Value picklist controls inactivity (15 min, 30 min, 1 hour, 2 hours, 4 hours, 8 hours, 12 hours, 24 hours). The Maximum Session Length controls absolute timeout (same picklist range from 1 hour to 24 hours). Profile-level overrides live under Setup, Profiles, profile name, Session Settings. The profile setting overrides the org-wide setting for users assigned to that profile, but only to make it tighter; a profile cannot extend timeout beyond the org maximum.
The warning popup and the force-logout option
Two adjacent settings control what the user experiences at timeout. The Disable session timeout warning popup option determines whether the user sees a session-about-to-expire warning 30 seconds before the timer hits zero. The default behaviour is to show the popup; admins disable it for kiosk-mode displays or shared workstations where a popup is intrusive. The Force logout on session timeout option determines whether the session is killed silently or the user is redirected to the login page with an explanation. The default is the redirect; security-conscious orgs sometimes enable the force-logout for cleaner audit trails.
Mobile session timeout behaviour
Mobile apps that authenticate against Salesforce (Salesforce Mobile App, custom apps using the Mobile SDK) run a parallel timeout configuration. The Salesforce Mobile App respects the org's session timeout settings but has its own warning popup behaviour because mobile apps cannot show a desktop-style countdown reliably. Custom mobile apps using OAuth refresh tokens behave differently: the OAuth refresh token has its own expiration (configurable on the connected app), which controls how long the mobile app can stay logged in without forcing re-authentication, independent of the session timeout that applies to interactive web sessions.
Lightning Experience vs Classic timeout behaviour
Lightning Experience and Classic share the same session timeout settings but behave slightly differently around the timeout boundary. Lightning's single-page architecture means most user interaction is JavaScript-driven and may not always register as activity for the inactivity timer; Lightning includes a heartbeat that pings the server every 30 seconds to refresh the timer when the tab is visible. Classic's older page-based architecture registers activity on every page navigation. The practical effect is that Lightning sessions usually stay alive longer for the same user activity pattern, especially when the user spends time on dashboards or list views.
OAuth tokens and session timeout independence
OAuth access tokens issued through connected apps have their own lifetime configuration that is separate from the org-wide session timeout. The Session Policies tab on a connected app sets the OAuth token's effective timeout: tied to the user's session (default), a custom timeout in hours, or a high-assurance policy that forces re-authentication. Long-running integrations typically use OAuth refresh tokens to renew access tokens without involving the user, which means the user's session timeout never applies to the integration. Misconfiguring the connected app's session policy is a common cause of API integrations breaking at unexpected times.
Tightening session timeout in practice and the user experience trade-off
Tighter session timeouts reduce the window an attacker has to use a leaked session token but increase friction for legitimate users. A 15-minute inactivity timeout is appropriate for finance and admin profiles where a forgotten browser tab is a real threat. A 4-hour timeout fits standard sales users who switch between Salesforce and other apps throughout the day. An 8-hour timeout suits operational dashboards that need to stay open for a full shift. The right setting is a policy decision driven by the data sensitivity of the role, not a one-size org default; profile-level overrides let admins make different choices per user population.
Configure session timeout for the org and specific profiles
Session timeout is set org-wide first, then optionally tightened per profile. The steps below cover both halves of the configuration plus the inspection and force-logout options for incident response.
- Open Session Settings
Go to Setup, Security, Session Settings. The page covers all session policies including the timeout picklists.
- Set the org-wide Timeout Value
Pick the inactivity timeout from the Timeout Value picklist: 15 minutes for the strictest control, 2 hours for the default balance, up to 24 hours for permissive workflows. The choice applies to every user not covered by a profile-level override.
- Set the Maximum Session Length
Pick the absolute timeout from the Maximum Session Length picklist: 1 hour for high-security contexts, 12 hours for the default, up to 24 hours for shift workers. The session ends at the absolute timeout regardless of activity.
- Override the timeout on sensitive profiles
Open the profile of a sensitive user population (System Administrator, Finance User, HR User). Edit the Session Settings section. Pick a tighter Session Timeout from the picklist. Profile overrides can only make the timeout tighter than the org default, not looser.
- Test by waiting out the timeout in a non-prod org
Log in as a representative user in a sandbox. Wait through the configured inactivity timeout without interacting. Confirm the warning popup appears at the expected time, and that the session ends correctly. Repeat with the absolute timeout to confirm the hard ceiling fires as expected.
The inactivity timeout in minutes or hours. The session expires after this period of no user interaction.
The absolute timeout from session start. The session ends at this ceiling regardless of activity.
Suppresses the 30-second-prior warning popup. Useful for kiosks; reduces friction for users who do not want the interruption.
- Profile-level session timeout can only make the org-wide timeout tighter, not looser. A profile cannot extend timeout beyond the org's Maximum Session Length, even for an exceptional user population.
- Lightning Experience sends a heartbeat every 30 seconds when the tab is visible, which can keep the inactivity timer alive longer than expected. Background tabs do not heartbeat, so a stale Lightning tab will still time out as designed.
- OAuth tokens issued by connected apps have their own session policy, independent of the org-wide timeout. An integration that breaks at unexpected times often has a misconfigured connected app session policy, not a Session Settings problem.
Trust & references
Cross-checked against the following references.
- Session SettingsSalesforce Help
- Profile Session SettingsSalesforce Help
- Manage Connected AppsSalesforce Help
- Identity and Access Management Decision GuideSalesforce Architects
Straight from the source - Salesforce's reference material on Session Timeout.
- Session SettingsSalesforce Help
- View and End User SessionsSalesforce Help
Hands-on resources to go deeper on Session Timeout.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What is Session Timeout?
Q2. What's the trade-off?
Q3. Where is it configured?
Discussion
Loading discussion…