System.setPassword in Apex: Set a Salesforce User's Password

System.setPassword sets a Salesforce user's password from Apex. It takes a user ID and the new password, applies it immediately and sends no email:

System.setPassword(userId, 'NewPassword1!');

That makes it the quickest way to get a batch of sandbox test users ready for a QA cycle without waiting on welcome-email links.

Syntax

public static void setPassword(Id userId, String password)

• userId: the ID of the User whose password you are setting.
• password: the new password, as plain text.
• Returns nothing. If the password is rejected, the call throws an exception instead.

A complete anonymous Apex example

Open the Developer Console (or run sf apex run against the org) as an administrator and execute:

User u = [SELECT Id FROM User WHERE Username = '[email protected]' LIMIT 1];
System.setPassword(u.Id, 'Uat-Tester-2026!');
System.debug('Password set for ' + u.Id);

For several users at once, loop over a query. Keep the password out of anything you commit. Pass it in at run time or generate one per user and hand it over through a secure channel:

String pwd = 'replace-me-at-run-time';
for (User u : [SELECT Id FROM User WHERE Profile.Name = 'QA Tester' AND IsActive = true]) {
  System.setPassword(u.Id, pwd);
}

Errors you will hit

• Password policy. The value must meet the org's policy: minimum length, required character mix, and password history. A short or reused password makes the call throw an exception that carries the policy message. Check Setup > Password Policies first. A profile can override the org-wide policy, so check the profile too.
• Bad user ID. A query that matches no user throws System.QueryException: List has no rows for assignment to SObject before setPassword runs. Check the username, and remember that sandbox usernames carry the sandbox suffix.
• SSO-only users. If users sign in through SSO and the org has disabled username and password login, a password you set has nowhere to be used.

What happens at first login

Setting a password does not always skip the "change your password" screen. Depending on the org's settings, Salesforce can still ask the user to pick a new password on first login. Several developers report that clicking Cancel on that screen lets the user continue with the assigned password. Treat that as observed behavior, not a documented guarantee, and test it in your own sandbox before you build a QA process around it.

setPassword vs resetPassword

Method	What it does	Use it when
System.setPassword(userId, password)	Sets a password you choose. No email.	Sandbox test users, scripted QA setup
System.resetPassword(userId, sendUserEmail)	Generates a new password. With true, Salesforce emails the user a reset link.	A real user needs a reset

resetPassword returns a System.ResetPasswordResult. When you pass false, getPassword() on that result returns the generated password, which is useful in a sandbox where email deliverability is set to System Email Only.

System.ResetPasswordResult result = System.resetPassword(userId, false);
System.debug(result.getPassword());

Rules I follow with it

• Sandboxes only. Setting known passwords for real people in production weakens security, and an auditor will ask why it happened. Real users get SSO or the standard reset flow.
• No hardcoded passwords in classes, test data factories or CI scripts.
• Clean up. Deactivate test users when the testing cycle ends, so a known password does not outlive its purpose.
• Prefer a permission set to a shared login when the goal is giving a tester different access. Shared credentials make the audit trail useless.

If you are deciding whether to script user setup in Apex or build it in Flow, the trade-offs are in Apex vs Flow.