# Settings Resolution

### A priority-based inheritance model in the new experience

#### <mark style="color:blue;">The new groups experience resolves settings through a priority-based model that replaces the legacy primary group and lock-conflict system</mark>

<div data-with-frame="true"><figure><img src="/files/8TcZPxMmcjAbkMgKY9kx" alt="A diagram showing two columns: On the left, Locked Settings shows an Account-Level down to User-Level hierarchy. On the right, Unlocked Settings means User-Level changes can flow up and back down to Account-Level Settings."><figcaption><p>How settings resolve in the new groups experience</p></figcaption></figure></div>

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.

#### <mark style="color:blue;">For locked settings, the resolution hierarchy flows from account level down through group priority</mark>

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.

#### <mark style="color:blue;">For unlocked settings, a user-modified value takes precedence over group and account defaults</mark>

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.

#### <mark style="color:blue;">A user inherits both the setting value and the lock state from their highest-priority group that manages the setting</mark>

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.

<div data-with-frame="true"><figure><img src="/files/Zzyg2GAVGCIyeW5GYHxQ" alt="A diagram showing a user, Jane, belonging to at least three groups. Each group has different settings, some unlocked, some locked, and some disabled and others enabled."><figcaption><p>How Jane, a user belonging to at least three different groups, inherits settings across those groups</p></figcaption></figure></div>

#### <mark style="color:blue;">Primary group designation is no longer a factor in settings resolution</mark>

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](https://support.zoom.com/hc/en/article?id=zm_kb\&sysparm_article=KB0066037#h_01FHGRGV8FNV5ZNN9ARRH8F1D6).

#### <mark style="color:blue;">The baseline and exception group pattern provides a predictable configuration framework</mark>

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.

{% hint style="info" %}
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.
{% endhint %}

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.

#### <mark style="color:blue;">Unselected settings in any group are not managed by that group and do not create conflicts</mark>

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.

#### <mark style="color:blue;">The new groups experience covers all settings that were available at the legacy group level</mark>

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.

#### <mark style="color:blue;">New settings released through monthly web updates follow the group's configuration level</mark>

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.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://library.zoom.com/admin-corner/account-and-endpoint-management/new-groups-and-settings-management-experience-explainer/settings-resolution.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.