Session Management
Session Management is a Setup page in Salesforce where administrators view and end active user sessions across the entire org.
Definition
Session Management is a Setup page in Salesforce where administrators view and end active user sessions across the entire org. It lists each session with the user, the session type, the login type, the time it started, and the source IP address, plus a Remove action that ends the session on demand.
You reach it from Setup by entering Session Management in the Quick Find box. The page covers browser sessions, OAuth and JWT access token sessions, and mobile app sessions. Removing a session forces that connection to authenticate again, which makes the page the place where security teams cut off a suspicious or stale login.
How the Session Management page works in practice
What a session actually is
A session is the authenticated state that ties a user to the org after they log in. Salesforce issues a session token, and every request the browser or client makes carries that token so the platform knows who is asking and what they are allowed to do. The session lasts until it times out, until the user logs out, or until someone ends it from Session Management. Until one of those happens, the holder of the token is treated as the logged-in user. That is why the page matters for security. A session token is a live credential. If an attacker captures one, they do not need the password, because the token alone proves identity for the rest of the session. The Session Management page is the inventory of every live token in the org and the switch that turns any of them off. It shows browser sessions, OAuth sessions from connected apps, JWT-based access token sessions, and mobile app sessions side by side, so you see the full picture of who is connected and how.
Reading the columns
Each row is one active session. The Username tells you whose session it is. The Session Type describes what created it, and Salesforce tracks several types: an interactive browser login (UI), a Visualforce page session, an Aura or Lightning session, a Content session for files, plus short-lived temporary types that the platform spins up for specific operations. Knowing the type helps you tell a normal user login from an integration token or a one-off content download. The Login Type shows how the session was established, such as a standard username and password login, single sign-on, or an OAuth flow. Login Time records when the session started, and the source IP address shows where the request came from. The Action column holds the Remove link. Read across a row and you can answer the practical questions during an incident: who is this, how did they get in, from where, and how long have they been connected.
Ending a session and what really happens
The Remove action ends a session immediately. The next request from that browser or client is rejected, and the person has to log in again before they can do anything. This is the response you want when an account looks compromised or when a contractor's access should have stopped at the end of an engagement. There is one timing detail worth knowing. For most Salesforce services, ending the session revokes the associated access token right away. For some services it can take up to 30 minutes before the token is fully revoked. So removing a session is fast, but it is not always instant across every connected surface. During a serious incident, pair the Remove action with other controls. Freeze or deactivate the user, reset the password, and review Login History so a fresh login does not simply reopen what you just closed. Removing the session stops the current connection; it does not stop a new login with valid credentials.
Session Management versus Session Settings
Two pages sound alike and do different jobs. Session Management is operational. It shows live sessions and lets you end them one at a time, after the fact. Session Settings is configuration. It sets the rules that govern every session before it starts, such as the Timeout Value, whether a timeout forces a logout, whether sessions are locked to the IP address they originated from, and whether login IP ranges are enforced on every request. You use them together. Session Settings is the policy. If you tighten the timeout to two hours and lock sessions to their origin IP, you reduce how long a stolen token stays useful and how easily it travels. Session Management is the enforcement of last resort. When something slips past the policy, or when you simply need to cut a specific connection now, this is where you do it. A good security cadence reviews the settings periodically and watches the live sessions for anything the settings did not catch.
Spotting trouble in the session list
The page earns its keep during scheduled reviews, not only emergencies. Patterns in the list reveal problems that no single login looks suspicious enough to flag. One user with many simultaneous sessions from several regions is a classic sign of shared or stolen credentials. An integration session that has held a token far longer than your rotation policy allows points to a missed credential rotation on a connected app. Treat the review as a habit. Open the page, scan the source IP addresses against the locations your users actually work from, and check the oldest sessions against your timeout and rotation policies. Anything that does not fit gets investigated and, if needed, removed. Catching a foothold here, before an attacker moves deeper, is far cheaper than cleaning up after data has left. The list is small enough to scan quickly in most orgs, which is exactly why building the habit pays off.
Doing it in code with Apex and the API
Most of the time you work from the Setup page, but session control is also available programmatically. The current session id can be retrieved in Apex, and the platform exposes the AuthSession object so administrators and developers can query active sessions through SOQL and the API for monitoring and automation. That lets a security team build a scheduled report of long-running sessions or feed session data into an external monitoring tool instead of opening Setup by hand. Salesforce also ships the Auth.SessionManagement Apex class for session-aware logic, including support for verification and session-based permission sets. Session-based permission sets are the natural partner here. They grant a sensitive permission only while a session is active and meets your conditions, so the extra access disappears the moment the session ends. Combined with High Assurance session security, which can require multi-factor verification before sensitive operations, you get fine control over what a given session is allowed to do, not just whether it exists.
Review and end active sessions from Session Management
Session Management is a monitoring and response page rather than a one-time switch. Here is how to use it to review active sessions and end a suspicious one. You need the Manage Users permission, which is included in System Administrator.
- Open the page
From Setup, enter Session Management in the Quick Find box, then select Session Management. The list of active sessions loads, covering browser, OAuth, JWT, and mobile sessions across the org.
- Scan the active sessions
Read across each row: Username, Session Type, Login Type, Login Time, and source IP address. Look for the same user logged in from several regions at once, or sessions far older than your timeout policy.
- Investigate anything that looks off
Cross-check a questionable IP address or an unusually long-lived session against Login History for that user. Confirm whether the activity is legitimate before you act.
- End the session
Select Remove on the row you want to cut. The session ends and that browser or client must log in again. Remember the token is revoked immediately for most services and within 30 minutes for some.
- Contain the account if needed
If the session was a real compromise, removing it is not enough. Freeze or deactivate the user, reset the password, and review what the session touched so a new login cannot quietly resume.
The user the session belongs to. Group rows by username to see anyone holding several sessions at once.
How the session was created, such as an interactive UI login, a Visualforce or Aura session, or a content session. Helps you separate user logins from integration tokens.
The authentication method behind the session, for example a standard login, single sign-on, or an OAuth flow.
Where the session's requests originate. Compare against the locations your users actually work from to flag impossible travel.
Ends the selected session on demand. The connection is rejected on its next request and must authenticate again.
- Removing a session is not always instant everywhere. The token is revoked immediately for most services but can take up to 30 minutes for some.
- Ending a session does not block a new login. If credentials are compromised, also freeze the user and reset the password, or they can simply log back in.
- The page shows only currently active sessions. For a full history of who logged in, from where, and the result, use Login History instead.
- Long-lived integration sessions are often legitimate, but a token older than your rotation policy on a connected app is worth investigating.
Prefer this walkthrough as its own page? How to Session Management in Salesforce, step by step
Trust & references
Cross-checked against the following references.
- View User Session Information on the Session Management PageSalesforce
- Session SecuritySalesforce
Straight from the source - Salesforce's reference material on Session Management.
Hands-on resources to go deeper on Session Management.
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 does the Session Management page let an administrator do?
Q2. During a security incident, how does Session Management help the responding admin?
Q3. Beyond emergencies, why review Session Management on a regular cadence?
Discussion
Loading discussion…