Legacy Model Context

Understand how the legacy model handled settings inheritance, user overrides, primary groups, locks, and conflict resolution.

How group management worked before the new experience

Zoom's settings hierarchy operates across three levels: Account, Group, and User

Zoom's administrative settings are organized in a three-tier hierarchy:

1. Account-level settings are the broadest, applying as defaults across the entire account.

2. Group-level settings allow administrators to customize settings for collections of users.

3. User-level settings are the most specific, applying to individual users.

Settings cascade downward through this hierarchy: account-level defaults flow to all groups and users below them.

When a setting is configured at the account level, groups and users inherit that value automatically unless it is overridden at the group or user level.

For more information on how tiered settings work across Zoom, see the Zoom Support article Using tiered settings. For an example of how this hierarchy applies to a specific product, see the Zoom Support article Zoom Phone group management.

A user who has modified an unlocked setting retains that value unless it's overridden by a lock

When a user manually changes a setting that is not locked, the user's chosen value takes precedence over the group-level and account-level values for that setting. This is referred to as the "modified" status. A modified user-level setting continues to take precedence over group-level and account-level values unless an administrator locks the setting at the account level or group level. At that point, the locked value overrides the user's modification.

This behavior applies in both the legacy group management model and the new groups and settings management experience. It is not specific to one model or the other.

In the legacy model, the primary group and lock state determined which settings took effect for users in multiple groups

When a user belonged to more than one group in the legacy model, the system designated one group as the primary group and all others as secondary groups. The primary group's settings generally took precedence over secondary group settings. When lock conflicts existed between groups—for example, one group locking a setting on and another locking it off—the system used a combination of primary group designation and the order in which the user was added to groups to determine which value applied.

For certain products, the legacy model applied the most restrictive setting across all groups a user belonged to. If a user was in one group where Zoom Chat was enabled and another where it was disabled, Zoom Chat would be disabled for that user because the system defaulted to the more restrictive value.

Account-level feature locks forced settings top-down with no group-level exceptions

When an administrator locked a setting at the account level in the legacy model, that locked value applied to every group and every user in the account, with no way to create exceptions. If an administrator wanted to enable a feature for a specific group of users while keeping it disabled for everyone else, they had to unlock the setting at the account level and then manually lock the desired value in every individual group. This action immediately removed that protection for all users.

This approach required administrators to create paired groups for every feature variation: one group with the feature locked on and another with the feature locked off.

As organizations needed more granular control over more features, the number of required groups expanded, increasing management complexity. Each new feature exception required additional groups, and each group carried all product settings tabs regardless of the group's purpose.