Defaults matter — most users never change a preference, so what they get out-of-the-box is what they experience forever. This article covers how preference defaults cascade across the platform.
The Cascade
- Platform default — the value baked into the preference definition.
- Tenant default — what the tenant admin set for all users in that tenant.
- Group default — some preferences can be set per security group.
- User value — the user's explicit choice.
The user value wins if set; otherwise the closest non-null upper layer is used.
Setting Tenant Defaults
- Open Site Settings → User Preferences.
- For each preference, set the tenant-wide default (or leave blank to inherit the platform default).
- Tick “Lock — users cannot override” for any preference that should be a tenant policy rather than a personal choice.
Setting Group Defaults
Group defaults are useful for role-specific overrides — e.g. setting the default landing page to “Dashboard” for managers but to “My Tickets” for support agents.
Worked Examples
- Healthcare clinic: Theme set to Light at tenant level, locked — high-contrast medical settings shouldn't change. Timezone defaults to the clinic's local zone but users can override if they work remotely.
- SaaS multi-tenant: Each tenant gets a different default landing page based on what their workflow centres on. Users can still override.
- Frontline staff: Group default for the “Density” preference is Compact (more data on screen for ops dashboards); management group inherits Comfortable.
- Localisation: Tenant default language follows the tenant's country, but users from international branches can pick their own.
Warning: Locking a preference means users see the option but cannot save changes — confusing UX. Hide locked preferences from the UI rather than leaving disabled toggles visible.