/settings (organisation) · Config Settings → /config-settings (engine)
Nyumba Zetu keeps configuration in one engine with one resolution rule, rather than scattering
switches across modules. Understanding the rule explains most “I changed it and nothing happened”
questions.
The scope chain
A setting is resolved by walking from the most specific scope to the least, and taking the first value found:Definitions and overrides
The settings engine has two halves:
A definition without an override uses its default. An override without a definition cannot exist.
Reading the definitions list
Reading the overrides list
Changing settings in context
You rarely need the raw engine. Most screens with configurable behaviour carry a settings gear that opens the settings for that area, filtered to its category and set at the scope you are working in. Changing a collections threshold from the collections console is safer than finding the key in a list of hundreds.Where each kind of configuration lives
Changing a setting safely
1
Decide the scope first
Ask whether this should be true for the organisation, or only for one branch or scheme. Setting
at too broad a scope is the most common configuration mistake.
2
Check for existing overrides
A more specific override will win regardless of what you set.
3
Make the change
From the contextual settings panel where one exists.
4
Verify against the behaviour, not the value
Open the screen the setting affects and confirm it did what you expected.
5
Record why
Settings changes are audited, but the audit records what changed — the reason is worth noting
for whoever reads it later.
A caution on inert settings
A setting only does something if a module reads it. When new configuration is introduced, its read-site is wired at the same time — a value that exists but is never read is worse than no setting, because it looks like a control and is not one. If you set something and behaviour does not change, and there is no more specific override, raise it rather than assuming the value is wrong.Feature flags versus settings
The two are converging onto one engine; today, module availability is managed under
Feature flags.