User Registration

How Accounts Are Created

Accounts arrive one of two ways: somebody registers themselves, or an administrator creates one for them. The choice shapes everything about who can reach your application.

Where to find it

Architect Panel → Configuration:

• Site Settings — the registration and welcome e-mail settings

Architect Panel → Security:

• Permissions — what a newly created account can reach
• User Verification — proving something about somebody before granting more

Self-registration

Anybody who can reach the page can create an account. Right for a public service, a customer portal, a marketplace — anywhere the population is open and you cannot know in advance who will arrive.

Administrator-created

Somebody inside the organisation creates the account. Right for staff systems and closed applications, where the population is known and membership is decided rather than claimed.

The question that actually matters

Not "should people register themselves" but what does a brand-new account get?

Self-registration is only safe if a new account can reach nothing sensitive. If registering gives somebody access to real data, then anybody in the world can have that access — and no amount of care in the registration form changes it.

Settle what a new account's permissions are before opening registration, and check by creating one and looking at what it can see.

Registration is not verification

Somebody who registers has demonstrated control of an e-mail address. They have not demonstrated who they are, that they work where they claim, or that they are entitled to anything.

Where those matter, that is user verification's job — and the useful pattern is to let people register freely into a low-privilege state and verify to gain more, rather than trying to police the registration form itself.

Expect abuse on an open form

A public registration form attracts automated sign-ups. Plan for it: rate limiting and account banning apply, and unverified accounts should be reaching nothing worth having.

A steady trickle of junk accounts that can see nothing is an annoyance. The same trickle with real access is an incident.

Both can coexist

Staff created by an administrator, customers registering themselves, with different default groups. That is usually the honest arrangement and it is worth setting up deliberately rather than forcing one model on both populations.

Think about leavers on both paths

Administrator-created accounts usually have a leaver process. Self-registered ones frequently do not, and accumulate indefinitely. Decide what happens to an account nobody has used for two years, because "nothing" is a decision you will have made by default.

Worked example

A membership organisation lets anybody register, which grants access only to public content and their own profile. Verifying membership through an e-mail domain check awards the Members group and the content behind it. Staff accounts are administrator-created. Registration abuse is visible and harmless, because an unverified account can reach nothing.

Recommendations

• Decide what a new account can reach before opening registration.
• Create one and look rather than assuming.
• Register freely, verify for access — do not police the form.
• Give self-registered accounts a lifecycle too.

What a New Account Can Reach

A new account arrives in whatever groups you have set as its default. That single decision determines what registration actually grants.

Where to find it

Architect Panel → Security:

• Permissions — what each group holds
• Record Access Roles — row-level access, which is separate

Architect Panel → Configuration:

• Site Settings — the registration settings

This is the setting to get right

Everything else about registration is process. This is the access.

If self-registration is open, then whatever the default groups grant is available to anybody in the world who fills in a form. That is fine if the answer is "almost nothing", and it is a serious exposure if it is not.

Start with nothing

The safest default is a group that grants access to a person's own profile and to genuinely public content, and nothing else. Everything beyond that should be earned — by verification, by an administrator, or by some other deliberate step.

Adding access later is easy. Discovering that a year of registrations could all read something is not.

Check it as a real new user

The only reliable method. Register an account yourself, through the actual form, and look at what it can see — the menus, the datastores, the browse views, the API.

Reasoning about it from the group configuration is unreliable, because access accumulates from several places and administrators see everything regardless.

Watch the All Users group

The one most often overlooked. Anything granted to All Users is granted to every account including new ones, and it does not appear in your default group configuration at all.

So a new account's access is the default groups plus whatever All Users holds — and the second half is invisible unless you go looking. Audit it whenever you review registration.

Different defaults for different routes

Where accounts arrive by several paths — self-registration, administrator creation, single sign-on, provisioning — they need not land in the same place. Somebody created by an administrator has been vouched for; somebody who filled in a form has not.

Verification is the upgrade path

The clean pattern: register into a minimal group, verify something, gain a group. That keeps the open door open without the open door granting anything, and it makes the grant reviewable — every member of the verified group got there by passing a check.

Review what the default group has accumulated

Permissions get added to groups over time, usually to solve something specific. A default group that was minimal two years ago may not be now, and nothing announces the change.

Put it on the same annual review as your other access work.

Worked example

A portal's registration default grants one group with read access to public articles and the user's own record. A test registration confirms nothing else is reachable — which turned up an All Users grant on a supplier datastore, added during a project and forgotten. It is moved to a specific group before registration opens.

Recommendations

• Default to almost nothing and earn the rest.
• Register a real test account and look through its eyes.
• Audit All Users whenever you review this.
• Use different defaults for different arrival routes.

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".

E-mail Address as Username

Use E-mail Address as Username ships on. With it off, users can have a username separate from their e-mail address.

Where to find it

Architect Panel → Configuration:

• Site Settings — Use E-mail Address as Username, and Login Page Mode

Why the default is on

• Nothing extra to remember. People know their e-mail address; they forget usernames.
• Uniqueness for free. No two people share an address, so there is nothing to arbitrate.
• One identifier for sign-in, recovery and contact.

For most applications this is straightforwardly right.

When a separate username helps

• Shared or role addresses. Several people using one mailbox cannot each have an account keyed on it.
• Users without an address, or without one you should hold.
• An existing convention — a staff number, a member number — that people already use and expect.
• Public display. If the identifier is ever shown to other users, a username avoids publishing e-mail addresses.

What you take on by separating them

A second identifier to manage. Usernames must be allocated, cannot be changed casually once referenced, and get forgotten — which turns "I cannot sign in" into two possible problems rather than one.

You also need to decide what happens when somebody's e-mail changes, and whether the username follows.

Recovery still runs on the e-mail address

Whatever you choose for sign-in, password reset needs an address to send to. So the address is required regardless — a separate username does not remove the need for one, it adds an identifier alongside it.

It interacts with the login page mode

E-mail check mode asks for an address first and adapts. That fits naturally when the address is the username, and less naturally when it is not — the page is asking for one thing to decide about another.

Consider the two settings together rather than separately.

Changing your mind is awkward

Turning this off after accounts exist means every user needs a username. Turning it on means resolving anybody whose address is missing, shared or duplicated. Neither is impossible and both are work — decide early.

Duplicate addresses

With the setting on, an address can belong to one account. That prevents duplicates, and it also means somebody who legitimately needs two accounts — a staff member who is also a customer — needs two addresses or a different arrangement. Worth thinking about if your populations overlap.

Worked example

A customer portal keeps the default, so customers sign in with their e-mail address and nothing else to remember. A separate internal system uses staff numbers, because those are already on everybody's badge and several field staff share a depot mailbox — with a personal address held for password reset.

Recommendations

• Keep the default unless you have a specific reason.
• Hold an e-mail address regardless — recovery needs one.
• Decide alongside the login page mode.
• Settle it early — changing later is real work.