Instance Configuration Fields

Instance configuration holds settings for the installation as a whole, rather than for a user or a tenant.

Where to find it

Architect Panel → Configuration:

• Custom User Information Fields — fields on user records
• Custom Tenant Information Fields — fields on tenant records
• Instance Configuration Fields — fields on the installation itself

Architect Panel → Security:

• Permissions — restricting who can see a value

This is where credentials land

The most important thing to understand about it. Every module needing to talk to something external puts its credentials here — API keys, connection details, tokens.

That makes instance configuration one of the most sensitive stores in the platform, and it is why the API's sensitive list blocks it outright regardless of any other setting.

Restrict it tightly

Access to this screen should be a small, named group. Somebody who can read it can read your integration credentials, which is access to other systems as well as this one.

Review who has it — this is exactly the permission granted for convenience during a project and never revisited.

Mark secrets as encrypted

Fields holding credentials should be flagged so they are stored encrypted rather than in plain text. A credential in an unencrypted configuration field is a credential in your database backups.

Remember the audit trail

Changes are recorded with before-and-after values, so the audit log for this table contains the credentials themselves. Who can read that audit log is therefore a similar question to who can read the configuration.

Group by module

Configuration accumulates from every feature anybody has ever enabled. Grouping by what a setting belongs to is the difference between a screen somebody can work with and a long list they scroll past.

Write help text and sensible defaults

These fields are edited rarely and usually under pressure, by somebody who did not configure them originally. A sentence of explanation and a working default prevent most of the guessing.

Prune retired modules

Configuration for something no longer used still holds its credentials. When a module or integration is retired, remove its configuration rather than leaving credentials lying in the database for a system nobody uses.

Record what is set

Not the values — the fact that a given integration is configured, who owns the credential and when it expires. That is what somebody needs during an outage, and the values themselves should stay where they are.

Worked example

An organisation restricts instance configuration to two administrators, flags every credential field as encrypted, and groups settings by module. When an integration was retired, its configuration was cleared rather than left — which a security review had previously flagged as three sets of live credentials for a system switched off two years earlier.

Recommendations

• Restrict the screen to a small named group.
• Encrypt every credential field.
• Consider who reads the audit log for this table.
• Clear configuration when a module is retired.