Had a question regarding session timeouts, renewals and renewing a security token using a connected app and the salesforce API.

We have an Azure function that acts as a mediator to pass data between our on-premise services and salesforce lightning instance. At the beginning of each request to the Azure Function, we send a request to the server using the client secret, password and other information and successfully receive our access token. However, we are seeing the INVALID_SESSION_ID after a certain period of time (usually in the morning)

I'm really new to connected apps and Salesforce as a whole so I wanted to learn more about why this is happening and what I can do to prevent it. This app on the cloud and is only used internally, so we are not worried about logging it out at all. We want it to stay active as long as the service is active, which should be all the time with the exception of maintenance.

Now for my laundry list of questions

  1. Our token does not appear to change during testing after certain period of time. When I am debugging I will successfully get the request token, then try again about 20-30 minutes later and the token will be the exact same. **Should this token change since I am making a new authorization request each time? I have a hunch that our session is expiring because of inactivity but I'm curious as to why the Token is always the same. **

  2. Seeing how this is an integration account, I do not want the session to expire. What makes a session expire? Does it have anything to do with this value on our connected app itself?

Session Policies

  1. The Updated By and Valid Until sections in Session Management are constantly updating. The Valid Until is always set to 2 hours after the Updated section. How are these values getting set? Are these something I can control?

Valid Until/Updated

Thank you all for the help in advance from a Salesforce Rookie!


1 Answer 1


An OAuth access token can be thought of as if it were a session id. If that session hasn't been revoked or timed out, then it won't change. The way Salesforce handles OAuth requests is less "give me a new session" and more "check if I already have a session. If I do, give me the session id, else make a new one".

All sessions in Salesforce have a timeout. As far as I know, there's no way to disable that (which, honestly, is a good thing). If memory serves, the maximum allowed timeout is 24 hours and the minimum is 15 minutes. With a connected app, you can configure the timeout in 3 places:

  1. In the connected app's policies
  2. In the profile of the user you're authenticating as
  3. At the org-wide level

The most specific timeout defined is the one that gets used. Specify it at the connected app level, and that's what your timeout will be for sessions started via that connected app. If you don't have it at that level, it'll look for that information at the user level, and then finally at the org-wide level.

Based on your observation, I'd hazard a guess to say that your timeout value is 2 hours. If you look for timeouts in order of precedence, you should find that value.

Each request you make with a valid access token causes the timeout to be reset (or so I think. sfdcfox's answer on your previous question makes me doubt that). It doesn't matter if the request you're making with that access token does anything (nor does your requested action need to succeed).

If your Azure function is making calls to Salesforce with enough frequency, then the session can functionally live forever. An integration I've been stuck with for the past 3+ years can maintain the same session for an entire year (up until we need to update the certificate used for the JWT Bearer OAuth flow).

Aside from that, the easiest way to handle this would be to just make a token request to /services/oauth/token prior to making your actual request. Perhaps a better way to handle this would be to try to make your request, and if it fails with INVALID_SESSION_ID, then try to get a new access token and retry the request.

  • thanks for filling me in with some much needed info. I started to do some digging and realized that my timeout value being empty was indeed inheriting the 2 hour timeout. I revoked my current sessions and after restarting my app the Valid Until number was 24 hours out. I ended up sending some few tests through and that is indeed updating. Hopefully that solved our issue! Commented Mar 23, 2021 at 0:10

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .