Settings Resolution

Learn how settings are inherited and resolved across account, group, and user levels using priority, locks, and user modifications.

A priority-based inheritance model in the new experience

The new groups experience resolves settings through a priority-based model that replaces the legacy primary group and lock-conflict system

How settings resolve in the new groups experience

The new groups and settings management experience introduces a settings resolution model built on explicit group priority rather than the legacy system's reliance on primary group designation, lock conflicts, and most-restrictive-setting logic. In the new model, each group has a numeric priority rank, where P1 is the highest priority and higher numbers represent lower priority. When a user belongs to multiple groups, the system evaluates which group's settings to apply based on this priority ranking.

The resolution model works differently depending on whether a setting is locked or unlocked. These two paths determine how settings apply across account, group, and user levels.

For locked settings, the resolution hierarchy flows from account level down through group priority

When a setting is locked at the account level, the account-level value takes absolute precedence. No group configuration and no user-level change can override an account-level lock, regardless of group priority. This behavior is unchanged from the legacy model.

When a setting is locked at the group level, the lock and its corresponding setting value are inherited from the user's highest-priority group that has the setting coupled to it. A locked setting in a lower-priority group has no effect if the user also belongs to a higher-priority group that manages the same setting. This is true even if the higher-priority group has the setting unlocked. In the new experience, priority exclusively determines which group's setting is applied; group-level locks do not affect precedence the way they did in the legacy model.

For unlocked settings, a user-modified value takes precedence over group and account defaults

When a setting is unlocked—meaning it has not been locked at the account level or at the user's highest-priority group that manages it—the user's own setting takes precedence. If a user has modified an unlocked setting, that user-level value is what takes effect. This "modified" status behavior is carried forward from the legacy model into the new experience.

If the user's highest-priority group has the setting locked, the locked value takes effect and the user cannot override it, regardless of any prior modification. A user-modified value only takes precedence when the setting is unlocked at both the account level and the user's highest-priority group that manages it.

If a user has not modified the setting, the value is inherited from the user's highest-priority group that has the setting coupled to it. If no group manages the setting, the account-level default applies.

A user inherits both the setting value and the lock state from their highest-priority group that manages the setting

When the system resolves a setting for a given user, it identifies the highest-priority group the user belongs to where that specific setting is coupled to the group. The user inherits both the value of the setting (on or off) and the lock state of the setting (locked or unlocked) from that single group. Lower-priority groups that also manage the same setting have no effect on the user's inherited value or lock state for that setting.

If none of a user's groups manages a particular setting, the setting falls through to the account-level default. Settings that aren't selected in any of the user's groups are not blocked or in conflict.

How Jane, a user belonging to at least three different groups, inherits settings across those groups

Primary group designation is no longer a factor in settings resolution

In the legacy model, the primary group played a central role in determining which settings took effect. In the new experience, primary group designation has been completely removed from settings resolution. The priority ranking system replaces it entirely.

The ability to designate a primary group is retained because Information Barriers still relies on the primary group field to create barriers. Administrators should be aware that while the primary group tag still exists, it has no bearing on which settings a user inherits under the new model.

For more information on Information Barriers, see the Zoom support site.

The baseline and exception group pattern provides a predictable configuration framework

An example configuration approach uses two types of groups working together. A baseline group contains all users in the account, has all settings tabs enabled, and is assigned the lowest priority.

This group functions as pseudo-account-level defaults: It establishes the default setting values and lock states that apply to every user, unless overridden by a higher-priority group.

There is a notable exception to the baseline group concept. Enabling all Zoom Phone settings in an "all users" group would override any site-level "policy" settings. This would occur even when settings are locked at the site level.

Exception groups are then created at higher priority levels, each configured with only the specific product settings tabs that need to differ from the baseline. Because the exception group has a higher priority than the baseline, users who belong to both groups inherit the exception group's values for the settings it manages, while all other settings continue to be inherited from the baseline group.

This pattern means that adding a new policy for a subset of users requires only one additional group with the relevant settings tab, rather than the paired enabled/disabled groups that were necessary under the legacy model.

Unselected settings in any group are not managed by that group and do not create conflicts

When a group is configured with only specific product settings tabs, any settings outside those selected tabs are simply not managed by that group. These unmanaged settings do not create conflicts, do not block inheritance from other groups, and do not override account-level defaults. They pass through as if the group doesn't exist for those settings.

This is a fundamental architectural change from the legacy model, where every group carried all product tabs and could unintentionally affect settings that weren't relevant to the group's purpose.

The new groups experience covers all settings that were available at the legacy group level

There are no settings gaps between the legacy group management model and the new groups experience. Every setting that was configurable at the group level under the legacy model remains configurable under the new experience. Administrators migrating to the new experience will not lose access to any group-level settings.

New settings released through monthly web updates follow the group's configuration level

When a group is configured with a full settings category, new settings added to that category through monthly web releases are automatically coupled to the group. However, if a group is configured with only individual settings within a category, no new settings are automatically added to the group. This means administrators who use granular individual setting selection maintain precise control over which settings each group manages, even as new features are released.

When a new settings category is added to an existing group, the group inherits the account-level values for that category at the time of addition.