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.