Set a session timeout you can defend, turn on force logout, and leave “lock sessions to the IP address from which they originated” switched off unless your network egress is genuinely fixed. That one checkbox generates more tickets than every other session setting combined. Protect the sensitive surfaces with high assurance session levels instead.
The settings that matter
They live in Setup under Session Settings, with a profile-level override for the timeout.
Timeout value. Fifteen minutes to twenty-four hours, measuring inactivity rather than elapsed time. A user working continuously is never timed out. The profile setting wins over the org default, which is the right lever: short for System Administrator, humane for everyone else.
Force logout on session timeout. With it off, a timed-out user can often carry on where they left off. With it on, the session ends. If you are setting a timeout for a compliance reason, this checkbox is the one that makes the timeout real.
Disable the session timeout warning popup. Leave the warning on. It is all that stands between a user and a lost half-completed record.
Lock sessions to the IP address from which they originated. The session becomes invalid if the client IP changes. It gets its own section below.
Enforce login IP ranges on every request. Profile login IP ranges normally apply at login only. This extends the check to every request, so a session that moves outside the range dies mid-use. Same failure mode as IP locking.
Why lock-to-IP causes complaints
Because client IP addresses change constantly, and almost never for a reason the user understands.
A laptop moving from office wifi to a hotspot changes IP. A proxy pool rotates outbound addresses. A VPN reconnects on a different gateway. In every case the user sees the same thing: they were working, and now they are on the login page, with no explanation and whatever they had typed gone.
The setting is defensible in a fixed-site environment where every user comes from a known static range. Everywhere else it converts a small theoretical risk into a daily reliability problem, and someone turns it off after a month of tickets. You get the disruption and then none of the protection.
Login IP ranges and trusted IP ranges are not the same
They get confused constantly, and they do opposite jobs.
- Login IP Ranges, set on a profile, are a hard block. Outside the range, the user cannot log in at all. This is the right control for an integration user, which should only ever connect from your servers.
- Trusted IP Ranges, set under Network Access, are the opposite: inside them, users skip the identity verification challenge for an unrecognised device. Nothing is blocked, and nothing is required.
Adding the office range to Network Access and expecting it to block logins from elsewhere is a common mistake. It does not.
High assurance sessions
This is the control worth using. Salesforce assigns each session a security level based on how the user authenticated: a plain password login is standard, a multi-factor login is high assurance, and you map SAML and other methods yourself on the Session Security Levels page.
You can then require high assurance for specific things. Reports and dashboards, connected apps, and login to a profile can each demand it. A user on a standard session who opens a protected area is challenged at that moment rather than at login.
That is a much better shape than blanket restriction. Ordinary work stays frictionless, and the export-everything surfaces get a real check at the point of use.
What else ends a session
Timeout is not the only cause, and knowing the rest saves you diagnosing the wrong thing:
- A password change invalidates the user’s other sessions.
- An administrator ending sessions from the Session Management page, or from the user record.
- The connected app’s own session policy, which can be shorter than the org’s and overrides it for that app.
If a user reports being logged out at odd moments, check the app they were in before touching org settings. A connected app with a thirty-minute policy does this to one person and nobody else.
Session timeout decides how long a session lives. Whether it can be created from a given address at all is a separate control, described in trusted IP ranges vs profile login IP ranges.
Frequently asked
Does the session timeout affect API tokens? Access tokens follow the session policy of the connected app that issued them, so a short timeout there shortens token life. Refresh token policy is a separate setting and the one people forget.
What timeout should we use? Long enough that people are not logged out during normal work, short enough to survive an audit. Two to eight hours suits most organisations.
Can I see who is logged in right now? Yes. Setup has a session management view listing active sessions, and you can end any of them there.
