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.