Site Settings

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.

Where Settings Come From

Configuration comes from two places: the application configuration file, and the settings held in the database.

Where to find it

Architect Panel → Configuration:

• Site Settings — the option groups, grouped by subject

Architect Panel → Configuration:

• Instance Configuration Fields — per-tenant values, a third source

The file

Holds values that need to exist before the database is reachable, values that should not be changeable from a web interface, and defaults. It is edited by somebody with access to the server, and a change requires a deployment.

The database

Holds the settings shown in Site Settings, editable by an administrator, taking effect immediately. Each setting mirrors a name the application reads.

Why some values stay in the file

Deliberately, and it is worth understanding rather than working around:

• Bootstrapping — database credentials cannot be held in the database.
• Security — some values should require server access to change, not merely an administrator account.
• Deployment discipline — a change that ought to go through review rather than a text box.

A setting marked not editable is a decision

Not an oversight. If a value appears in the file and is not offered in Site Settings, somebody decided it should not be changed casually.

Per-tenant values are a third source

Instance configuration holds values per tenant — credentials, endpoints, limits. So "where does this value come from" can have three answers, and it is worth knowing which applies before changing anything.

Know which source you are editing

The commonest confusion in this area is changing one and expecting the other to follow. A value edited in the file while the database holds its own copy produces a change that appears to do nothing.

Check both when diagnosing

When a setting is not behaving as configured, look at both sources before anything else. It is a thirty-second check that resolves a surprising proportion of configuration problems.

Keep the file under version control

Or at least backed up, with a record of changes. It is configuration that only exists on a server, and a server can be replaced.

Never put secrets in the file if you have somewhere better

Credentials belong in instance configuration, where they are encrypted and restricted. A key in a configuration file is a key in every backup and every copy of the codebase.

Worked example

An organisation keeps bootstrapping values and deployment settings in the file under version control, feature settings in Site Settings, and every credential in instance configuration. A setting that "would not change" turned out to be one where the file value was authoritative — found by checking both sources first.

Recommendations

• Know which source holds the value before editing.
• Check both when a setting misbehaves.
• Version-control the file.
• Credentials in instance configuration, not in the file.

When Settings Disagree

A setting that does not do what it says is one of the more frustrating problems to diagnose, and the causes are few.

Where to find it

Architect Panel → Configuration:

• Site Settings — the option groups, grouped by subject

Architect Panel → Activity:

• Error Log — where a rejected value is often recorded

Work through these in order

1. Which source is authoritative? File or database. This is the answer most of the time.
2. Is it a per-tenant value? The tenant’s own configuration may differ from the installation default.
3. Was the value accepted? A value failing validation may not have been stored.
4. Is something caching it? Configuration read at start-up is not re-read because you saved a form.
5. Does anything actually read it? A setting nothing consumes is a setting with no effect.

The last one is the uncomfortable case

A setting that exists, is editable and is read by nothing at all. It looks like a control and enforces nothing, which is worse than having no setting — an administrator believes something is switched on when it never was.

If a setting appears to do nothing, consider that it might genuinely do nothing.

Two settings for the same idea

The related trap. Where a feature has been reworked, an old setting name can survive alongside a new one, and only one is read. Shipping both names for the same idea is exactly how somebody ends up trusting a control that was never implemented.

When you find a pair, establish which is live and remove the other.

Check the error log

Rejected values, missing configuration and misconfigured integrations usually write something. It is quicker than reasoning about it.

Test the behaviour, not the field

The only proof that a setting works is the behaviour changing. Set it, then do the thing it is supposed to affect — sign in, upload a file, trigger the notification.

Change one, test, then the next

When several settings interact — session, timeout, login, security — changing them together makes the result unattributable. It is slower and it is the only reliable method.

Record what you established

"This setting is authoritative in the file", "this one is read by nothing". These findings cost real time and are lost immediately unless written down.

Worked example

An administrator could not make a password rule take effect. Working through the list found two settings for the same idea, one of them read by nothing. The live one was set, the dead one removed, and the finding recorded — which saved the next person the same afternoon.

Recommendations

• Check the source first — it is usually the answer.
• Consider that a setting may do nothing.
• Test the behaviour, not the saved value.
• Write down what you established.