Built-in Groups
Five groups exist from the start. Two of them behave differently from the rest, and knowing which saves confusion.
Where to find it
Architect Panel → Security:
- Permissions — what these groups are granted
- Record Access Roles — row-level access, granted separately
The five
- Super Administrator — full administrative access.
- All Anonymous Visitors — everybody who is not signed in.
- All Users — everybody who is signed in.
- Restricted Accounts — for accounts that should be held back.
- Store Owners — a commerce administrative group.
Two are automatic, not assignable
All Anonymous Visitors and All Users are memberships the platform decides. You do not add anybody to them, and they do not appear as options when managing somebody's groups.
They exist so you can grant something to everybody signed in, or to the public, without maintaining a list. That makes them powerful in one direction: anything granted to All Users is granted to every account you have, including ones created tomorrow.
Treat All Users carefully
It is the right place for genuinely universal access — a staff directory, a policy library. It is the wrong place for anything you would want to review, because there is no membership to review.
Check what it holds periodically. A permission added to All Users for a good reason three years ago is a permission everybody now has, and nothing about it will look unusual.
All Anonymous Visitors is a public grant
Anything granted to it is available without signing in. That is occasionally exactly right — a public register, a form the world may submit — and it deserves deliberate review, because it is the one group whose grants are visible to anybody at all.
Super Administrator
Full administrative capability, and effectively exempt from the restrictions you configure elsewhere. That has two consequences worth stating:
- Membership should be short and reviewed. Two or three people, not a dozen.
- You cannot verify any permission configuration while signed in as one, because you will see everything regardless.
Do not repurpose the built-ins
They are shipped with meanings the platform relies on. Renaming one to suit a local convention, or using Restricted Accounts for something other than restricting, produces a system whose behaviour does not match its labels — and the next administrator will believe the labels.
Worked example
A review of what All Users can reach finds read access to a datastore added during a project two years earlier, which now holds supplier contact details. It was invisible in every access review because the group has no membership list. The permission is moved to a specific group, and All Users is added to the annual review checklist.
Recommendations
- Audit what All Users can reach annually — nothing else will surface it.
- Review anonymous grants deliberately; they are public.
- Keep Super Administrator to two or three people.
- Never verify permissions as an administrator.