# Key Capabilities

### Each group can be configured with only specific product settings or more granular individual settings for select products

#### <mark style="color:blue;">Administrators select which product settings categories are included in the group and unselected categories fall through to account-level defaults</mark>

In the new groups and settings management experience, administrators can configure each group with only the product settings categories relevant to that group's purpose. This replaces the legacy model where every group automatically carried all product settings tabs, regardless of whether those settings were relevant to the group.

When creating or editing a group, administrators choose which settings categories—such as Meetings, AI Companion, Recording and Transcript, or Zoom Chat—the group should have. Any categories that aren't selected aren't included in that group.

For those unselected categories, users in the group inherit their settings from the next source in the resolution hierarchy: the next highest-priority group that manages the setting, or the account-level default if no group manages it.

This modular approach means a group created specifically to manage AI Companion settings for a subset of users doesn't unintentionally affect those users' Meeting or Zoom Chat settings. Each group manages only what it's configured to manage.

#### <mark style="color:blue;">Granular per-setting selection provides control at the individual setting level within select product categories</mark>

Beyond selecting entire product settings categories, administrators can select individual settings within a category.

Individual setting selection within product categories is currently available for the following primary settings areas:

* AI Companion
* Audio Conferencing
* General
* Meetings
* Recording & Transcript
* Webinars

When a group is configured with a full settings category, new settings added to that category through monthly Zoom web releases are automatically coupled to the group. However, when a group is configured with only individual settings within a category, no new settings are automatically added. Administrators who use granular, individual setting selection maintain 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.

### Explicit priority ranking determines which group's settings take effect

#### <mark style="color:blue;">A numeric priority ranking replaces the legacy primary group designation and lock-conflict model</mark>

The new groups experience introduces explicit priority ranking for all groups with settings enabled. Each group is assigned a numeric priority, where P1 is the highest priority and higher numbers represent lower priority. When a user belongs to multiple groups that manage the same setting, the highest-priority group's value takes effect.

This replaces the legacy model's reliance on primary group designation and lock-state conflicts to determine which settings apply. In the new model, priority exclusively determines which group's setting applies for any given user. Group-level locks do not affect which group takes precedence. They only affect whether the user can modify the inherited value.

For more information on how tiered settings work across Zoom, see the Zoom Support article [Using tiered settings](https://support.zoom.com/hc/en/article?id=zm_kb\&sysparm_article=KB0065579).

#### <mark style="color:blue;">Administrators can adjust priority order at any time through drag-and-drop or CSV upload</mark>

After migration or initial group creation, administrators can reorder group priorities at any time through the Priority Management interface in the Admin console. Groups can be reordered using drag-and-drop functionality or by uploading a CSV file with the desired priority assignments.

Priority changes take effect immediately for all affected users.

### Groups can exist without any settings attached for organizational purposes

#### <mark style="color:blue;">Settingless groups support use cases where group membership is needed without affecting user settings policy</mark>

The new experience allows administrators to create groups that have no product settings attached. These settingless groups don't participate in settings resolution and don't receive a priority ranking, which means they can't create unintended policy side effects or conflicts.

Settingless groups support organizational use cases where group membership serves a purpose other than settings management. Examples include:

* Workspace reservation neighborhoods, where specific desks or spaces are reserved for members of a group.
* App marketplace assignment, where a third-party app is approved for members of a specific group rather than all users in the account.
* Compliance role scoping, where an admin role is configured to manage only users within a specific group, allowing scoped administrative access without full account-level privileges.

### Account-level locking helps administrative control remain above the priority system

#### <mark style="color:blue;">Account-level locks override all group and user settings regardless of priority</mark>

Account-level locks represent the highest level of administrative control in the settings hierarchy. When a setting is locked at the account level, the locked value applies to every group and every user in the account.

No group, regardless of its priority ranking, can override an account-level lock. This behavior is unchanged from the legacy model.

Account-level locks should be reserved for settings that must be universally enforced across an entire tenant. For example, enforcing settings required by regulatory compliance or organization-wide security policy where no exceptions are permitted.

#### <mark style="color:blue;">When an account-level lock is removed, groups inherit the account-level setting value at the time of removal</mark>

If an administrator removes a lock at the account level, the setting becomes configurable at the group level. When the lock is removed, all groups inherit the account-level setting value as their new default:

* If the setting was enabled when unlocked, all groups default to enabled.
* Conversely, if the setting was disabled when unlocked, all groups default to disabled.

Administrators can then configure the setting differently in individual groups as needed.

#### <mark style="color:blue;">Group-level locking within the priority system provides more flexible default control than account-level locks</mark>

For settings where most users should be restricted but a subset of users needs access, Zoom recommends using group-level locking within the priority system rather than account-level locks. This approach works by keeping the setting unlocked at the account level, then locking the desired default value in a baseline group that contains all users at the lowest priority. Higher-priority exception groups can then override the baseline group's lock for specific users.

This pattern allows administrators to enforce a default setting for the majority of users while granting exceptions to specific groups without the paired enabled/disabled group creation that was required under the legacy model's account-level lock approach.

### Identity provider integration: SAML multi-mapping and SCIM support for enterprise group membership

#### <mark style="color:blue;">SAML multi-mapping allows users to be assigned to multiple groups through a single SAML assertion when they log in</mark>

The new experience includes optional SAML multi-mapping support, which allows a single SAML assertion to match multiple mapping rules and assign a user to multiple Zoom groups at login. Up to 50 rules can be matched per assertion. This enables a one-to-one mapping between identity provider (IdP) groups and Zoom groups, so that adding a user to a security group in the IdP automatically assigns them to the corresponding Zoom group at their next login.

Without multi-mapping enabled, SAML mapping matches only the first applicable rule and assigns the user to a single group.

{% hint style="info" %}
For organizations interested in SAML multi-mapping, please [contact Zoom Support](https://support.zoom.com/hc/en/contact?id=contact_us) and make a request.
{% endhint %}

#### <mark style="color:blue;">SAML mapping becomes the authoritative source for group membership and removes users from non-matched groups</mark>

When SAML mapping is configured, either with or without multi-mapping enabled, it becomes the authoritative source for group membership. At each login, the SAML assertion determines which groups the user belongs to. If a group is not matched by the assertion, the user is removed from that group.

This means that administrators cannot combine SAML-mapped group assignments with manual group assignments through the Admin portal or through CSV import for the same user. If a user is manually added to a group that isn't included in their SAML assertion, the next login will remove them from that manually assigned group.

{% hint style="info" %}
If your organization uses SAML mapping to manage group membership, you should use it for all group assignments for SAML-mapped users.
{% endhint %}

#### <mark style="color:blue;">SCIM group push behavior is unchanged in the new experience</mark>

SCIM-based group push continues to work the same way in the new experience as it did in the legacy model. When a user is added to a group in the identity provider, the corresponding Zoom group membership update occurs within an hour.

SAML requires a user to log back in to the Zoom Workplace app or web portal for group membership changes to take effect. From a timing perspective, if both SCIM and SAML multi-mapping are active and processing the same group membership change, SCIM would likely take precedence because it updates without requiring user action.

SCIM and SAML multi-mapping should not be configured with conflicting group information. While both mechanisms can coexist on the same account, mismatched configurations, such as those where SCIM and SAML assign a user to different groups, will create conflicts.

### Settings audit and reporting offer CSV-based exports for account, group, and user-level settings visibility

#### <mark style="color:blue;">The Settings Snapshot report exports account-level and group-level settings for pre-migration baselining</mark>

The **Settings Snapshot** report, available under **User Activity Reports** in the Admin console, exports account-level and group-level settings as a CSV file. This report provides a baseline record of the current settings configuration, which can be used before initiating a migration to the new groups experience. Administrators can use it to document existing group purposes and settings configurations.

#### <mark style="color:blue;">The User Settings report audits per-user settings with inheritance source attribution</mark>

The **User Settings** report is an enhancement introduced with the new Groups experience. It allows administrators to export a CSV showing specific settings values and lock states for all users in the account, along with the source from which each user inherits the setting, be it a specific group, the account level, or a user-level modification.

Administrators select a specific subset of settings within a category to audit, since the report covers all users in the tenant and can be large for accounts with thousands of users. Each row in the exported CSV shows:

* The user
* The setting value (on or off)
* The lock state
* The group or level the setting is inherited from

### Existing APIs remain compatible with the new experience

#### <mark style="color:blue;">Legacy Groups APIs continue to work, but have not been updated with new Groups features</mark>

The existing Groups APIs remain fully compatible with the new groups and settings management experience, including endpoints for user assignment, group creation, and group listing. Accounts that have migrated to the new experience can continue using these APIs without modification. An existing group's Group ID will also remain the same after migration.

The APIs have not yet been updated to support features introduced with the new experience, including group cloning, priority management, and granular setting configuration. These operations are currently available only through the Zoom Admin console.

For the full API reference, see the [Groups API documentation](https://developers.zoom.us/docs/api/users/#tag/groups).

### Administrators can duplicate a group's configuration to a new group

#### <mark style="color:blue;">The copy/clone feature reduces configuration effort when creating groups with similar policy requirements</mark>

Administrators can duplicate an existing group's settings configuration to a new group using the copy/clone feature. This is useful when creating multiple groups that share a common settings baseline, but differ in membership or specific setting values.

Copying a group's configuration creates a new group with the same product settings tabs, individual setting selections, and setting values as the source group. Administrators can then adjust individual settings in the new group as needed without configuring them from scratch.


---

# 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/key-capabilities.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.