Welcome E-mails
Two settings, both shipping on, controlling whether a new user is e-mailed — and they are deliberately separate.
Where to find it
Architect Panel → Configuration:
- Site Settings — the two welcome e-mail settings, plus the account and templates
Architect Panel → Layout & Pages:
- E-mail Templates — the message itself
Architect Panel → Activity:
- E-mail Log — whether it was sent
Why two settings
The two situations are genuinely different.
Somebody who registered themselves is at the keyboard, expecting something, and knows why they are receiving it. Somebody an administrator created an account for may know nothing about it — the message may be their first indication the account exists.
The second message therefore has to do more work, and being able to configure them separately is the point.
What a self-registration message needs
- Confirmation the account exists.
- How to sign in.
- What to do next, if anything — verify, complete a profile.
- Who to contact if they did not register.
What an administrator-created message needs
All of the above, plus context they do not have: who created it and why. An unexpected e-mail saying an account has been created for you, with no explanation, looks exactly like phishing — and the more careful your users are, the more likely they are to ignore it or report it.
Name the organisation, say why, and where possible say who asked for it.
Never send a password
Send a link that lets them set one. A password in an e-mail sits in a mailbox indefinitely, gets forwarded, and is readable by anybody with access to that mailbox.
Say what to do if it was not expected
An account created for somebody who did not ask, or a registration somebody did not make, is the first sign of something worth knowing about. Give a route to tell you — and make sure that route reaches somebody who will act.
Keep it plain
A short, plainly branded message from a recognisable address gets read and acted on. An elaborate one looks like marketing and, for a security-relevant message, like phishing.
Check delivery before you rely on it
If the welcome message carries the only route to setting a password, a message that does not arrive is a user who cannot start. Test against the mail providers your users actually use — corporate filters are the usual obstacle — and check the e-mail log when somebody reports not receiving one.
Consider whether to send at all
Where accounts are provisioned automatically from a directory, a welcome e-mail may be noise — the user already has access through single sign-on and never thinks about the account. Turning it off for that population is reasonable.
Worked example
An organisation sends both messages. The administrator-created one names the manager who requested the account and explains what it is for, after several people had reported the previous version as suspicious. Neither message contains a password — both link to set one, valid for a short window.
Recommendations
- Configure the two separately — they do different jobs.
- Explain who created it and why in the administrator message.
- Never send a password.
- Give a route for "I did not expect this".