How to Reset a Salesforce User Password

Sometimes you need to set a Salesforce user’s password directly, without knowing the current one and without sending them through the email reset flow. A locked-out integration user, a shared sandbox account, or a test user whose inbox nobody monitors are all common cases.

System.setPassword() does this in one line from the Developer Console. Here is how, plus what it does not do, which matters more than the code itself.

What you need first

An admin account, or specifically the Manage Users permission
Access to the Developer Console, which needs Author Apex
The exact username of the target user, which is the full username including the org suffix, not their email address

Steps

Log in to your admin account.
Open the Developer Console from the gear menu in the top right.
Open Debug > Open Execute Anonymous Window, then run the following:

System.setPassword(
    [SELECT Id FROM User WHERE Username = 'YOUR USERNAME'].Id,
    'YOUR PASSWORD'
);

Replace both placeholders with the real username and the password you want to set.
Click Execute. A successful run logs nothing and simply completes.
Confirm by checking the debug log opened, or by logging in as that user.

What this does not do

This is the part that surprises people, and it is worth knowing before you use it on a real person’s account:

The user is not notified. No email is sent. If it is a colleague’s account, you have to tell them yourself.
It does not force a password change at next login. The password you set is the password they keep. The standard Setup reset does force a change; this does not.
It does not bypass your password policy. The value still has to satisfy the org’s complexity, length and password-history rules, or you get an INVALID_NEW_PASSWORD error.
It is recorded. The action appears in Setup Audit Trail against your user. This is a feature, not a problem, but do not treat it as invisible.

The alternative: System.resetPassword

If you want Salesforce to generate the password rather than choosing one yourself, use resetPassword instead. It returns the generated value and can optionally email the user:

// second argument: send the user an email or not
System.ResetPasswordResult result = System.resetPassword(userId, false);
System.debug('Temporary password: ' + result.getPassword());

A password set this way is temporary and the user must change it at first login, which is usually what you want for a real person. setPassword is the better fit for service accounts and test users where nobody is going to complete a change-password prompt.

When to use which

setPassword: integration users, sandbox test accounts, service accounts, anything automated where a forced change would break a login.
resetPassword: real people, where a temporary credential and a mandatory change is the correct security posture.
Setup > Users > Reset Password: the normal path for a colleague who can receive email. Prefer this when it is available.

Common errors

List has no rows for assignment to SObject: the username did not match. Usernames include the org suffix, for example jane@company.com.sandboxname.
INVALID_NEW_PASSWORD: the password fails your org’s policy, or it reuses one from the password history.
INSUFFICIENT_ACCESS: your user lacks Manage Users, or the target has a higher-privilege profile than you.
Nothing appears to happen: that is success. This method returns void and logs nothing on completion.

One caution

Setting another person’s password to a value you know means you can log in as them, and anything done in that session is attributed to them rather than to you. For anything involving a real colleague’s account, prefer the standard reset flow or Login Access so the audit trail stays honest about who did what.

Post Views: 5,954