Site Settings
Site Settings holds the installation’s configuration, organised into groups by subject.
Where to find it
Architect Panel → Configuration:
- Site Settings — the option groups, grouped by subject
Settings are grouped by subject
Rather than listed alphabetically. There are groups for Global, User Account & Login, Session, Security, Passwords, Two-factor Authentication, Passkeys, Date/Time, Tables, File Uploads, Error Logging, the Admin Panel, and around twenty more covering specific features — Stripe, Cookie Consent, Service Workers, Mobile Apps, the OpenID Connect provider, SMS and WhatsApp, Business Intelligence, the API server, and others.
Knowing that the grouping is by feature is usually enough to find something: a setting about e-mail marketing is in the E-mail Marketing group, not in Global.
Each setting is a defined field
With a name, a friendly name, a description, a type, a default, validation, and whether it can be edited here at all. So the settings screen is built from a definition rather than hand-written, which is why the types and validation behave like any other field in the platform.
Read the description
Every setting has one. It is the difference between setting a value correctly and guessing, and it is right there next to the field.
Some settings are not editable here
A few are marked as not user-editable, because they belong in the application configuration file. If you cannot find something you expected, that is usually why — it is a file-level setting rather than a database one.
Restrict who can reach it
These settings decide how authentication, sessions, security and integrations behave for everybody. Access should be a small named group, and it is exactly the permission granted during a project and never reviewed.
Change one thing at a time
Especially in the security, session and login groups. Several changes at once, followed by a problem, is a problem you cannot attribute.
Write down what you changed
Settings changes are the least documented and most consequential thing an administrator does. A dated note of what changed and why answers the question that arrives three months later.
Test after security changes
Anything touching sessions, passwords, two-factor or login should be followed by an actual sign-in, from an account that is not yours, ideally on a device that is not yours.
Worked example
An organisation restricts Site Settings to two administrators and keeps a dated change note. When sign-in behaviour changed unexpectedly, the note identified a session-timeout change made a fortnight earlier, which took two minutes rather than an afternoon.
Recommendations
- Search by feature group, not alphabetically.
- Read the description before setting a value.
- Restrict access to a small named group.
- Keep a dated change note.