We are going to do one big release (deployment, configuration, data load) in our prod org and need to have some sort of maintenance window to prevent users from interacting with SF org.

Freezing all users except the one responsible for deployment and configuration seems like a good idea, but some additional questions have popped up:

  1. Would scheduled jobs still be executed under frozen user account? And what about scheduled reports? Ideally we would like everything to be blocked.
  2. Some of our external systems are using special integration users to communicate with SF relying on access and refresh tokens received by passing through OAuth2 flow. Would these tokens be invalidated if such integration users were frozen?
  3. Is there any impact of doing freeze and unfreeze back? E.g. when disabling users and then enabling back again territory assignments are gone. Would be our users able to continue working after being unfreezed as nothing happens with their accounts?

Any help would be appreciated.

  • Pretty sure scheduled jobs fail to execute in this case (I'm sure we had this issue a couple of years ago on one customer org). Can't comment on the other bits.
    – Phil W
    Dec 19, 2019 at 16:00
  • It is preferred if you can post separate questions instead of combining your questions into one. That way, it helps the people answering your question and also others hunting for at least one of your questions. Thanks!
    – identigral
    Dec 20, 2019 at 18:07

1 Answer 1


Freezing a user is really about stopping them from logging in as opposed to some of the side affects of deactivation (failed jobs with user). I don't necessarily have official documentation, but I simply tested some of your scenarios. Might be useful to see if you confirm this behavior if you're also testing.

  1. Scheduled Reports still send. Although it seems more of a bug than by design. Here's an older idea questioning this and it doesn't seem to have changed. https://success.salesforce.com/ideaView?id=08730000000kyGeAAI

    Scheduled Jobs still run successfully

  2. They wouldn't work. Again, logging in is affected and seems to affect this on my initial testing with a user and workbench oauth where it logged me out in the middle of my session when I attempted to query. I would assume this applies to integration trying to get an access token as they cannot log in successfully as a frozen user.

  3. Again, no official documentation but haven't seen any noticeable affects. They simply were not able to log in and then were once you select "unfreeze". This makes sense as the impact is really to the ability to "log in" versus any permissions or ownership issues.

  • 1
    Yep, we've observed the same behaviour in our testing - reports and jobs are still working, but oauth tokens are invalidated for frozen user. Haven't found any side effects of freezing user so far. Going to block reports and jobs, since for our use case with having custom maintenance window they should not be running.
    – wesaw
    Dec 26, 2019 at 19:09
  • #2 - existing access tokens won't be invalidated, you have to explicitly revoke them.
    – identigral
    Dec 27, 2019 at 16:20

You must log in to answer this question.

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