Not verified hands-on. This article was written from primary documentation rather than reproduced in an org, so it carries no tested-release badge. If you run it and something differs, say so in the comments and it gets tested and corrected.

Login, registration and password behaviour for a site are configured in the site’s Administration area under Login &amp. Registration, and password policy comes from the external user’s profile, not from the org-wide password settings everyone checks first. Self-registration is driven by an Apex controller you are expected to edit, and the single most common failure in production is a username collision, because usernames are unique across every Salesforce org in existence, not just yours.

What the Login &amp. Registration page controls

Each of login, self-registration, forgot password and change password can point at one of several things: the default page, an Experience Builder page, a Visualforce page, or an external URL. That last option is how you put login on your own marketing site and hand off to Salesforce afterwards.

The same screen holds the sender address and the email templates used for welcome, forgot password and change password messages. These default to something generic. Change them before launch, because they are the first message a new user receives from you.

Self-registration and the handler

Ticking the self-registration box assigns a default controller and an account. The account matters: every self-registered contact needs a parent account unless you are using person accounts, and leaving the default means every customer lands on one shared account record.

The work happens in the controller, which calls the platform method that creates the external user:

Contact c = new Contact(LastName = surname, Email = email,
                        AccountId = ACCOUNT_ID);
insert c;

User u = new User(
    Username = email + '.portal',
    Email = email, LastName = surname,
    Alias = surname.left(8), CommunityNickname = nickname,
    ProfileId = PORTAL_PROFILE_ID, ContactId = c.Id,
    TimeZoneSidKey = 'Europe/London', LocaleSidKey = 'en_GB',
    EmailEncodingKey = 'UTF-8', LanguageLocaleKey = 'en_US'
);
String userId = Site.createExternalUser(u, ACCOUNT_ID, password);

Note the username. Appending a site-specific suffix to the email address is not decoration, it is the fix for the collision problem. A person who already has a login at another company’s Salesforce community will fail registration silently otherwise, and the error surfaced to them says nothing useful.

Two more things bite here. Duplicate rules on Contact block the insert, and the generic failure page gives no clue why. And an existing contact with the same email produces either a duplicate or an exception, so decide deliberately whether registration matches an existing contact or always creates one.

Password policies live on the profile

Open the external user’s profile, not Setup’s password policies, and you get the settings that actually apply: minimum length, complexity, expiry, history, lockout period and the failed-attempt threshold. This is deliberate, because a portal for consumers usually wants a gentler policy than an internal org, but it means the setting is somewhere nobody looks.

Both password flows honour those profile settings, and a policy tightened after launch applies at the next password change rather than immediately.

Single sign-on and the registration handler

If users arrive from an identity provider rather than registering, the equivalent piece of code is a class implementing the registration handler interface, with a create method and an update method. It runs on first login, decides whether to match an existing user or create one, and assigns the profile.

Write the matching logic explicitly. A handler that matches on email alone will happily attach a new employee to a departed one’s account if the address was recycled. Match on a stable identifier from the provider and keep email as a secondary check.

What is worth customising, and what is not

  • Worth it: branding the login page, the email templates, a registration form that collects the fields your business needs, and the username strategy.
  • Worth it if relevant: passwordless login through a login discovery handler, and identity verification for higher-value portals.
  • Usually not: rebuilding the forgot-password flow. It works, it is secure, and custom versions leak information about which addresses exist.

Frequently asked

Why does registration fail with no error? Check the username is unique across all orgs, check duplicate rules on Contact and Account, and check the guest user‘s profile can reach the classes involved. Add a try/catch that logs to a custom object. The default page tells you nothing.

Can I require email verification before activating a user? Yes. Create the user inactive and activate on confirmation, or use identity verification. Do not leave a self-service portal open to unverified addresses.

Do external users need MFA? It is not imposed on them the way it is internally, but it is available and worth enabling for anything holding financial or personal data. Login flows are the usual route.

Can two community users share an email address? Email is not required to be unique, but the username is. Two family members on one address is workable. Two people sharing one login is not.