In a B2B SaaS product, a setting can affect the entire platform, an organization, or just one person. If each level has different values and the interface does not explain which one applies, surprises follow: users see different behavior, administrators cannot enforce a policy, and support teams have to investigate ambiguous configurations.
Inherited settings solve this problem when decisions follow a genuine hierarchy. The goal is not to add levels preemptively, but to determine who should decide each setting, which exceptions make sense, and how to communicate the effective value. An explicit model prevents flexibility from turning into a collection of hard-to-maintain special rules.
When to introduce inheritance
Inheritance is useful when there is a stable relationship between decision-making levels. For example, the product can provide a default; an organization administrator can adapt it to the organization’s policies; and each user can personalize it for their work, provided those choices do not conflict with an organizational requirement.
Not every setting needs a hierarchy. If a value is personal and does not depend on a shared policy, a user preference may be enough. If the value must be the same for everyone for security reasons, perhaps only an authorized person in the organization should be able to configure it. Unnecessary levels increase the burden of design, permissions, testing, and support.
Before implementing inheritance, identify the decision behind each field. Ask who is responsible, who needs an exception, and what the consequences of a change would be. If you cannot answer clearly, keep the setting simple until you have a use case that justifies inheritance.
Choose levels based on who makes each decision
A common model distinguishes three levels:
- Product default: provides consistent initial behavior for organizations that have not chosen another value.
- Organization: lets an administrator adapt settings to shared processes, policies, or needs.
- User: offers individual personalization when it does not conflict with the organization’s decision.
These levels are not mandatory. Add a level only if an actor needs to make that decision and has the appropriate permissions. Large organizations may have different administrative roles, but that does not necessarily mean those roles need to become separate settings levels. Often, it is enough to define who can edit organization settings.
It is also worth separating preferences from policies. A preference generally allows an individual choice, such as a display option. A policy expresses a rule the organization intends to enforce. Confusing the two can allow a personal preference to override a decision that should have been mandatory.
Define precedence and exceptions explicitly
An easy-to-explain rule is that the most specific applicable value takes precedence: user, then organization, and finally product default. But this rule only works if the setting allows overrides at all those levels. Security or compliance requirements may call for different logic: the organization sets a mandatory value, and the user cannot change it.
For that reason, define precedence by setting type rather than treating it as a universal promise. For each field, document the base value, the levels that can edit it, who can override it, and whether a policy can lock editing. The interface and server logic must apply the same rule; hiding a control on screen is not a substitute for validating permissions on the server.
It is useful to distinguish between “no custom value” and “a value equal to the default.” In the first case, the setting is inherited and can change when the higher-level setting changes. In the second, there is an explicit choice that should be preserved. If the system treats these states as equivalent, it cannot correctly explain where the value came from or preserve the user’s intent.
Show the effective value and its source
People who manage settings need to know both the active value and what determines it. Showing only the final value hides whether it was inherited or explicitly selected. A label such as “Inherited from product” or “Set by organization,” on the other hand, makes the source visible and reduces uncertainty about what will happen if someone edits the setting.
Offer actions that match the user’s permissions: change the value, reset it to inherit again, or find out why it cannot be edited. If the organization has enforced a policy, explain that the setting is locked and indicate which level or role can change it. Avoid messages that suggest an option is available when the user is not authorized to apply it.
When a user resets a setting, confirm the effect clearly: the value will no longer be an exception and will follow the higher-level configuration. If inheritance could change later, say so. This prevents “reset” from being interpreted as permanently locking in the value currently displayed.
Manage changes without erasing exceptions
Changing the product default should affect those who inherit that value, not those who chose an explicit exception. The same applies when an organization changes its settings: users who inherit from the organization should follow the new value; users with their own choice should change only if that exception is allowed and the action is clearly defined.
Before rolling out a change, identify which records represent inherited values and which represent explicit decisions. Do not infer intent solely because a stored value matches the current default. Preserve the inheritance state so the system can recalculate the effective value after an update.
If the product needs to change its default behavior, communicate which groups will be affected and what will happen to exceptions. When appropriate, let administrators review the change before it is applied to an organization. For important administrative operations, record who changed the setting and when, in line with the product’s support and auditing needs.
Test combinations, permissions, and edge cases
Testing should cover more than the usual value. Check every combination of levels: everyone inherits, the organization chooses an option, the user creates an exception, and an organizational policy blocks that exception. Also verify what happens when a value is removed or reset and when the higher-level default changes.
- Permissions: confirm that each role can view and edit only what it is allowed to.
- Consistency: check that the interface, APIs, and internal processes return the same effective value.
- Updates: make sure changing a level affects those who inherit from it without overwriting explicit choices.
- Missing data: define the outcome when a value does not exist or an older configuration does not contain the field.
- Explainability: verify that the application can show the value’s source and the reason editing is blocked.
One sign of a poor design is that support cannot answer “Why does this person see this value?” without manually inspecting several tables. Another is that administrators do not know whether a change will affect specific users. If these symptoms appear, review the model and how the value’s source is presented before adding more exceptions.
Checklist for a maintainable hierarchy
- Assign an owner and a purpose to each setting.
- Define the necessary levels and remove those without a clear use case.
- Specify precedence, permissions, locks, and exception rules for each field.
- Represent the effective value and inheritance state separately.
- Explain the value’s source and what resetting it means.
- Test changes to higher-level settings, permissions, and incomplete configurations.
- Document which exceptions the system preserves and how significant changes are audited.
Good inherited settings do not offer the maximum number of options. They make it clear who decides, what is inherited, and when an exception is valid. When every setting has an understandable and testable rule, the product can evolve without turning its preferences into a constant source of conflict.