Multi-tenant settings should show the effective value, where it came from and who may change it. Separate platform defaults, tenant overrides and user preferences. A configuration screen can appear correct while the application applies a different inherited value if precedence rules are unclear.
Let’s plan your tenant settings.
Bring your workflow, constraints and open questions. We’ll help you define the requirements and work through a practical next step.
Define the configuration hierarchy
List each setting's purpose, type, valid values and scope. Decide whether an unset value means inherit, disabled or unknown. Those meanings should not share one ambiguous blank field.
For a hypothetical SaaS reminder setting, the platform may supply a default while an organisation chooses a different schedule. A user preference may further affect personal delivery, but should not silently change a required operational queue.
Build an effective-settings register
| Situation | Behaviour to define | Evidence to show |
|---|---|---|
| No override | Apply approved default | Source and effective value |
| Tenant override | Use permitted organisation value | Actor and change version |
| User preference | Apply only within allowed scope | Relationship to tenant policy |
| Default changes | Which tenants inherit the update? | Impact preview or change record |
| Invalid value | Reject or follow defined recovery | Useful validation message |
| Reset | Remove override, not guess a value | Resulting inherited setting |
Do not let configuration create an accidental security bypass. Access and action authority need explicit enforcement regardless of the visible setting.
Make changes reviewable
For consequential settings, explain affected workflows before saving. Identify whether a change applies immediately, at the next run or only to newly created records.
Keep audit history appropriate to the configuration's impact. Support should be able to explain which version affected a past job without having to reconstruct the value from today's screen.
Test inheritance and isolation
Create synthetic tenants with default, overridden and user-level values. Change the platform default and verify the intended population changes while other tenants remain correctly isolated.
Include cache behaviour and delayed configuration refresh. A successful save should not imply that every component has applied the value instantly unless that has been established.
Configuration questions
Should every customer variation become a feature flag?
Not necessarily. Durable configuration and temporary rollout controls need different ownership and lifecycle rules.
Is reset the same as setting the current default explicitly?
No. Inheritance may follow later default changes; a fixed override may not. Explain the difference.
Use feature flag lifecycle guidance, and discuss precedence rules with Drema's SaaS developers.