Fix Guide

How to Fix Salesforce Session Timeout and Forced Logout Issues

Step-by-step fix guide with AI-powered diagnosis from BuildForce.

Salesforce session timeouts trip up users and integrations in different ways: org-level Session Settings (Setup → Session Settings) define defaults, profile-level Session Timeout overrides per profile (shorter always wins), Connected App OAuth policies override for API sessions, and Login IP Ranges can force re-auth from non-trusted IPs. The fix path: for interactive users, raise the profile Session Timeout and disable 'Force logout on session timeout'; for integrations, set the Connected App's session timeout to 'None' and refresh tokens to 'Valid until revoked'; for long-running Apex, use queueable/batch with @future or platform events to avoid spanning a single session.

Session Settings HierarchyProfile OverrideConnected App SessionLogin IP Range

Get AI-Powered Diagnosis See Pricing

Symptoms

Users prompted to log in again after 15-30 minutes of activity, not just inactivity

Integration jobs that ran successfully for months suddenly failing mid-run with INVALID_SESSION_ID

Lightning experience showing 'Your session has expired' modal during active work

Apex scheduled jobs failing on the second hour of a multi-hour run

Users behind corporate VPN experiencing aggressive logout while others on direct internet stay logged in

API integration timing out exactly at the connected app's max session duration

Root Causes

Profile session timeout overriding org default

If the org setting is 8 hours but a profile is set to 30 minutes, users on that profile time out every 30 minutes. Profile timeout always wins when set. Many orgs inherit short timeouts from cloned admin profiles without realizing.

Connected App Session Timeout not set to 'None' for integrations

Connected Apps inherit the org's session timeout by default. For server-to-server integrations, the access token expires at the session timeout. If 'High Assurance Session Required' is also enabled, the entire session is invalidated requiring re-OAuth.

'Force logout on session timeout' enabled in Session Settings

When this checkbox is on, the user is forcibly logged out at timeout — they don't get a 'continue working' prompt. If they had unsaved changes, those are lost. Combined with short timeouts, this creates constant user friction.

If the org has Login IP Ranges defined and the integration server's egress IP isn't in the range, every API call requires re-auth via SMS or email verification — which obviously can't happen for a server. Tokens are repeatedly invalidated.

High Assurance Session policy on connected app

When the connected app requires 'High Assurance' session, simple username/password authentication doesn't qualify. The integration succeeds in obtaining a token but the token is treated as 'Standard Assurance' and immediately invalidated for restricted operations.

How to Fix It — Step by Step

Audit the session timeout hierarchy

Start with the user's effective timeout. The shortest of (Org Session Setting, Profile Timeout, Connected App Session Policy) wins. Setup → Session Settings shows org-level; Setup → Profiles → [Profile] → Session Settings shows profile override.

Example

SELECT Id, Name, UserType, SessionTimeoutInMinutes 
FROM Profile 
WHERE SessionTimeoutInMinutes < 480 
ORDER BY SessionTimeoutInMinutes

Disable forced logout for active users

In Setup → Session Settings, uncheck 'Force logout on session timeout' (label may vary by org). This shows a re-auth prompt instead of dumping the user. Users on long forms or unsaved work no longer lose data on timeout.

Set Connected App session timeout to 'None' for integrations

Setup → App Manager → [Connected App] → Edit Policies → Session Timeout Value: select 'None' (use system default at session creation, no additional timeout). This is required for long-running and scheduled integrations.

Configure refresh token policy for integrations

In the same Connected App Edit Policies screen, set 'Refresh Token Policy' to 'Refresh token is valid until revoked'. Without this, refresh tokens expire on a schedule (default 90 days) and your integration breaks weeks after deployment.

Add integration server IPs to Login IP Ranges or use Relax IP

Either add the integration server's egress IPs to the Connected App's IP Relaxation (allow from any IP), or whitelist them in the org's Login IP Ranges. For cloud deployments with rotating IPs (Vercel, AWS Lambda), 'Relax IP restrictions' on the connected app is the only viable option.

Migrate long-running synchronous Apex to async patterns

Synchronous Apex callouts and DML operations share the user's session. For multi-hour jobs, use Queueable Apex with chaining or Batch Apex. These run as system context and aren't affected by user session timeouts.

Example

public class LongRunningProcessor implements Queueable {
  public void execute(QueueableContext context) {
    // long-running work
    if (moreWorkRemaining) {
      System.enqueueJob(new LongRunningProcessor());
    }
  }
}

Implement proactive token refresh for OAuth integrations

Don't wait for INVALID_SESSION_ID — refresh tokens proactively at 90% of their lifetime. This prevents mid-operation auth failures and is the pattern used by mature integration platforms.

Let BuildForce diagnose and fix this automatically

Instead of following manual steps, connect your org and let our AI identify exactly what's broken and how to fix it — in minutes.

Book a Demo

Common Questions

More answers about this issue and how to resolve it.

Stop debugging manually. Let AI do it.

BuildForce runs 200+ automated checks across your Salesforce org and tells you exactly what's broken and how to fix it.

Book a Demo View Pricing